The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Exposing biz objects to web services without code duplication?

I'm looking for some guidance on the best way to setup a facade to my biz objects so I can expose parts of them as a web service.

I want our customers to be able to add inventory items to our system through a web service. I have an InventoryItem class in my biz objects, but I really just want to expose an abstraction of that to our customers. So my web service has a class called "SimpleItem". (Not the real name, just work with me here..)

The problem is that the SimpleItem class has several properties that are enumerations or other custom classes. That means my web service now has to define these enumerations and custom classes so that callers to the service have access to them. These custom classes and enumerations are defined in my biz objects DLL that I don't want to expose completely. I just want to expose a handful of them in my web service DLL.

So how I can avoid having to duplicate my code here and still let my web service callers have access to a small number of custom classes inside my biz objects?

FWIW, I'm using C#.
Whatever
Friday, February 24, 2006
 
 
I don't really see a way to avoid some duplication. What you probably to do is create structs and array of structs that your webservice can use. These would be an abstraction on top of you objects. This way you can decouple your internal biz objects from external entities. This has the added benefit that you can change your internal biz objects without breaking the web service.

HTH!
slartibartfast Send private email
Friday, February 24, 2006
 
 
Hi Whatever,

If I understand your situation correctly, then I would recommend *removing* the objects from your business layer and keep them in the web service.

Whenever you add reference to a web service in VS, Visual Studio generates the code you need to interract with that web service.

This means that if you have a public struct or enum in your web service, your code can make use of that object locally without consuming any network traffic.

In short, expose all of your enums/structs in the web service, and then just add a "using" clause in your class libraries so that they end up using the web service version. This eliminates the duplication and there will *not* be a runtime performance hit
PWills Send private email
Friday, February 24, 2006
 
 
I don't think that using the classes generated by Visual Studio as your business objects is a good idea. Not only you have way too little control over how they are generated, but you will get too tied by the web service, which is definitely not a good thing. The web service is just a facade of your business logic and, like OP said, you don't want to always expose the whole functionality.
OP, you can do some workarounds, but you will always end up with some duplication. I see this as a case where duplication is not necessary a bad thing.
smalltalk Send private email
Monday, February 27, 2006
 
 
Example where generated code does not do what you would expect it to do:
public enum E
{
 A = 1, B = 2
}
On the client side you will get:
public enum E
{
 A = 0, B = 1
}
Which is bad if you want to save the values in a database.
How you could avoid duplication is this case? Write the enums on both sides with the values you want and write a generic method that converts from one enum to the other one based on *the name* of the field.
smalltalk Send private email
Monday, February 27, 2006
 
 
In order to map your business objects to the objects coming from the web service, you could define a custom attribute that you place on every property that needs to be mapped. Then you can iterate the properties having that attribute and copy the values to/from the instance of the generated class.
smalltalk Send private email
Monday, February 27, 2006
 
 
> public enum E
> {
>  A = 1, B = 2
> }
> On the client side you will get:
> public enum E
> {
>  A = 0, B = 1
> }

Smalltalk, I never knew about that behavior. Thankfully, every enumeration I have ever written is zero-based, so none of my applications need to be re-written. In fact, I didn't believe it when I read that, but you are absolutely correct.

You still should have one authoritative source for your enumeration. I do think duplication is a bad thing in this case. If the OP is using a database he may wish to write a small script to generate the C# enumeration code from the database table. It's better than having two copies which could potentially get out-of-sync.
PWills Send private email
Monday, February 27, 2006
 
 
Theoretically speaking code duplication is the worst thing one can do. But this situation is really debatable. I tried once to use the generated objects as my business objects, but I had only trouble. Later I arrived to the idea that the web service parameters should be no more than data holders.
Also, web methods tend and SHOULD not change or change very seldom, because lots of clients could break anyway. So having this duplication here makes you think twice before modifying web service parameters.
smalltalk Send private email
Monday, February 27, 2006
 
 
Lots of people seem to talk about this issue lately - http://ronua.ro/CS/forums/1/4371/ShowPost.aspx (in romanian, sorry), http://donxml.com/allthingstechie/archive/2006/02/26/2563.aspx .
smalltalk Send private email
Monday, February 27, 2006
 
 
I guess I'm confused on this.  Any reason why you couldn't move the duplicate code into its own DLL, then use that DLL in both your web service and application?
another anonymous coward
Monday, March 13, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz