I agree and I had taken your position already. I didn't want the business layer to contain all the xml serialziation stuff; to me, that's just bloat.
As a result, I'm taking a webservice and only having a few methods that take an xml document as a request and send an xml document as a response. I have seperate dll's that handle the business rules that the webservice itself will use. Thanks, Mike On 7/12/06, Don Demsak <[EMAIL PROTECTED]> wrote:
Mike, Check out this post by Matt Berther, "Web service and custom serialization" http://www.mattberther.com/2006/05/000755.html. In that post, Matt is running into issues where he is trying to reuse his business objects as message objects, because he doesn't want " two copies of the objects", one for XML serialization and one for the business entity, which sounds like you are trying to do a similar thing. The best practice is that if you are using business objects, odds are that you will need a separate message object to serialize. My detailed response was: I'd suggest that you have 2 copies of the "objects", even though you think it stinks. You have to remember that even though the "objects" have the same name, they are actually built to accomplish 2 different goals. The class that you have now, it is a business object, and thus has to conform to your business rules (which is part of the reason why you don't have a default constructor). Business classes contain the business data and the business behaviors. On the other hand, you have this representation of your business object that you wish to pass along the wire. The representation is a message, and not a business object. This class will contain a representation of the data contained within the business object, but as it is a message, it contains no business rules. Once you decouple the message from the business object, you will have an easier time distinguishing between your core business rules, and your message rehydration rules. In do so, you are also better able to handle versioning of your public facing contracts (in web services this is done via WSDL and XML Schema). You can now update and change your business objects as needed, and only add any new data to your message when that new functionality is required. By going down this path you will also be able to utilize the more enterprise friendly Web Services Contract First approach to building web services. I know that there are a lot of people that will disagree with me, and feel as you do, that by splitting things into messages and business objects, you are just adding to the bloat of a system, but I've learned that as long as you don't hit the architectural issues that you discuss here, that yes, the message based methodology is overkill for your particular project. But once you start to see that there are differences between the way you want to implement the business object, and the way you want to represent it on the wire, then you need to start to think about going down the message path. A comprising between these 2 designs is to implement the IXmlSerializable interface, on your business classes, but eventually this will also become too cumbersome and you will have to go the route of the message methodology, especially when you have to handle multiple minor versions of your message coming thru the same web service. Don Demsak www.donxml.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
=================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
