Use serialized domain model entities as web service messages?
I am wondering about the viability of using domain entity classes as the return types and method arguments in web services. The motivation is to avoid having to create a layer of data-transfer/message classes, and the mapping of domain objects to/from them. Technically it works - the IDE autogenerates the proxy classes and does all the serialization. But when you get into the particulars of the domain entity classes (their relationships with each other, aggratetions, exposed collectons, etc), I can see there being practical problems.
[547 byte] By [
ALFKI] at [2007-12-28]
I agree with Roger that a pure message based (Xml based) interface for your web service is the best way to go, but I have found need to compromise on this on more than one occasion. Usually I do not choose to compromise, but it forced on my the consuming application. For example: Using the Business Data Catalog with Microsoft Office SharePoint server forces you to compromise on this front as it is considerbly harder to build a BDC connection to a message based web service than to an entity based web service.
However, if I am building a enterprise application for a closed system or a controlled system, I would always default to a message based interface as it provides the greatest flexibility for integration, versioning and compatability. Exposing your business entities through a web services only opens you up to more issues, especially when you are building proxies against a Wsdl rather than distributing them yourself. It is far too easy for a consumer to break your business rules, which then requires you to spend extra time building in rule checks in your web service. In the end this can all be avoided with a well thought out messaging interface.
-Graham
