All, This is a design opinion question. In brief, I am developing a system for a client. The code includes a class called Foo. Foo might run on a machine connected to a database. It might also run on a machine without a connection to the database --- but it could talk to another machine in the middle with database access. Graphically:
MACHINE A (DB ACCESS) FOO ---------------------> Talks to DB MACHINE B (NO DB ACCESS) FOO ---------------------> Talks to Machine X -----> Talks to DB So, data access methods on a Foo living on Machine A must behave differently than those on Machine B So, I have 2 (or more?) options... 1. Create another class, FooProxy, the knows how to talk to Machine X, etc. to get to the DB. Both Foo and FooProxy implement the IFoo interface. So, client code on Machine A does a (IFoo)new Foo() and client code on Machine B does a (IFoo)new FooProxy() and away we go. 2. Use custom proxies. Machine A and Machine B client code do a "new" the same way. The custom proxies intercept the call and do "the right thing" depending whether they are Machine A or B bound. This makes the client code unaware of the differences. However, #2 makes the implementation (much) more complex than solution #1. Opinions? For "maintenance" and "clarity" I am leaning more towards #1, especially since the client is just getting started w/ .NET. All opinions welcome. Thanks. John
