4

I have to access a legacy database that has "generic" tables in it and I do not have the authority to change it. Depending on the customer data that I'm working with, the relationships between the tables may differ. So, customerA may join to the order table by only their customer number while CustomerB may join to the order table by customer number and the date. CustomerC may not join to the order table at all but to a different table.

So, what I would like to do is to create an object graph for CustomerA and one for CustomerB and one for CustomerC. I thought about creating a wrapper class for each but have been researching proxies. That said, the examples that are written about Proxy classes make them look identical to a wrapper class. Thus my question, are proxy classes synonymous to wrapper classes.

Thank You.

4 Answers4

4

No, they are not the same. Have a look at Proxy pattern and Wrapper pattern at Wikipedia.

Basically, a proxy is an object that looks the same as the original object (i.e. implements the same interfaces), but does something more.

Wrapper is an object that looks differently than the original object, but usually does the same.

svick
  • 236,525
  • 50
  • 385
  • 514
2

There are a couple of ways of handling the problem at hand.

One is to map to a common domain model. This works fine if you have the same basic behavior, but might not serve you well in the particulars (different keys for different types of clients).

Another is to move the common bits down into a base class and then inherit for the different specifics in state (different properties) or the different behaviors (primary key only id, etc). Considering this is both differing behavior and state, this is a direction you can use.

Now, patterns. A proxy pattern is one where the new object can provide some of the behavior and state of another object, but is not the object. Think of it like what a person voting for you as a proxy means, and then relate it to software. I would not think of it like a wrapper, as a wrapper is normally used to present a different face from the underlying object. This can be due to the need to hide something in the underlying object or to add further behavior on top of the object. The proxy pattern will not help with the varying keys; Possible with the wrapper, although I am not convinced it is the simplest way to do this.

Gregory A Beamer
  • 16,870
  • 3
  • 25
  • 32
  • Then, my next question is, if you suggest a wrapper, how can I implement this using Entity Framework? Should I post that as another question on stack overflow? –  Jul 19 '11 at 13:54
  • I would consider another question, as stack overflow is very segmented and you will get more EF specific answers. The hard part with your schema is the differing primary keys, but if each customer only uses one schema at a time, you can set it up as an install choice and only use one per instance. This would work well with EF. – Gregory A Beamer Jul 19 '11 at 13:59
1

From wikipedia: "A proxy, in its most general form, is a class functioning as an interface to something else"

ProxyPattern

Proxy: is an "interface", it's a "blackbox", if you like, from which you request something and it gives you back what you want.

Wrapper: is a entity which basically hides a functionality by encapsulating, so hiding inside it a "real" component/another class/... by exposing to the caller its own methods, so the user of wrapper has no clue with which object it really works.

Hope this helps.

Regards.

Chris
  • 1,533
  • 2
  • 17
  • 33
Tigran
  • 61,654
  • 8
  • 86
  • 123
0

Looking at the implementation a proxy and a wrapper class might be very similar. However the terms are often used in different meenings.

A proxy is an object that behaves like the real object, but isn't. Instead it forwards all calls to the real object, hiding the complexity of accessing the remote object. An example of proxy objects are the WCF clients genereated by Visual Studio. The client calls them as if they were the real service code, and the proxy handles the communication.

A wrapper is an object that for some reason hides another object. Usually this is done when interfaces are not compatible. An object with the right functionality, but the wrong interface, is wrapped in another object that translates the interface.

Anders Abel
  • 67,989
  • 17
  • 150
  • 217