Designing WCF Objects - OOP and SOA

Question

What is the right way to handle polymorphic business objects in the WCF / SOAP world?

It seems to me that SOA and OOP do not agree with each other - to set up a pure WSDL, you need specific objects, as a rule, without even using inheritance. On the other hand, presumably in the base system, you will want to follow the correct OO design.

What do people usually do here? Build a set of objects for a WCF contract, abandon the principles of OOP, and then convert to another set of objects in and out of real logical layers?

Answer 1

What do people usually do here? Build a set of objects for a WCF contract, abandon the principles of OOP, and then convert to another set of objects in and out of real logical layers?

Yes.

How WCF serializes ends up creating a lot of restrictions on what you can and cannot do with contract objects. What you cannot do is "the most useful."

I found that this makes a lot more clear if you think of the objects of the WCF contract as a data transfer mechanism. Basically, how strongly / statically typed XML.
Instead of converting a business object to an XML string (and vice versa), you convert your business object to a WCF contract object (and vice versa), but otherwise similar

Answer 2

After reading the Thomas Earl library, I came to the following conclusion:

Think of the WCF contracts / SOAP message as just the message that the Services use to communicate (do not drag out the binding to the objects in your code).

You can then use OOP to develop a code base that gracefully processes these messages using common OOP methods.

Answer 3

You use an abstraction (interface type) annotated by WCF attributes to define your service contract.

It depends on the abstraction that corresponds to the OOP, as well as the definition of the service endpoint, which is SOA.

In general, if you find yourself getting business objects with dependencies, you should consider moving those dependencies to the business service level, rather than overlaying dependencies on business objects. Then, the business service level will act as an intermediary, acting both for the WCF service proxy server and for business objects. Unlike business objects, they act on the WCF proxy server.

Answer 4

All great comments on this topic! I will add my voice to the concept of an adapter for mediation between service orientation and object orientation. I also like the approach of Thomas Earle, where in his service model he introduces the concepts of "applied services" and "business services." This is the way for your integration points with your specific application / business environment (i.e. your object-oriented and component platform / API). This method should lead to a significantly better layout and, therefore, to the opportunities for you, the guru of the business infrastructure.