In our organization, we\'ve shifted to a more \"service oriented architecture\".

Question

In our organization, we've shifted to a more "service oriented architecture". To give an example, let's assume we need to retrieve a "Quote" object. This quote has a shipper, a consignee, phone numbers, contacts, email addresses, and other location information. In other words, a Quote object is made up of many other objects.

So, it seems like it would make sense to make a "Quote Retrieval Service". In our situation, we've accomplished this by creating a .NET solution and writing the service. The service API looks something like this (in pseudo-code):

Function GetQuote(String ID) Returns Quote
So, so far so good. Now, when this service is consumed, to keep things "de-coupled", we are creating essentially a duplicate of the Quote object and mapping from the QuoteService version of the Quote into the consumer's version of the Quote. In many cases, these classes will have the exact same properties.

So, if the Quote service is consumed by 5 other applications, we would have 6 definitions of what a "Quote" is. One for each consumer, and one for the service. This feels wrong. I thought code was supposed to be DRY, but it seems like our method of SOA is forcing us to create tons of duplicated class definitions. What are we doing wrong, or is the code duplication just a "necessary evil" of SOA?

Explanation / Answer

JGWiessman is correct in that the lack of DRYness in auto-generated proxies is not costly, because you do not maintain the client's generated code. Change it on the server, update your references on the clients, job done.

However, there is an alternative, if both the client and the server are .NET. You can put all your objects in a separate assembly, referenced by both the client and server. If you then auto-generate the client code, it is simply an interface, using the same objects that the server uses.

Only do this if the objects you are sharing are dumb data objects and don't include any server-side code though, otherwise you're exposing that code to your client.

If both client and server are using the same version of .NET, you can take this one step further and include the interface purely by configuration. But you need to be careful here. The interface on the server side requires the ServiceContract attribute and thus references the ServiceModel assembly, so if the versions are different, you can get into trouble.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.