Passing Business Objects through tiers?

Passing Business Objects through tiers?

• TaiChiMaster

  This obviously going to cross multiple practices and opinions, but I'll throw out my take.   If you are looking at samples or other instructional code, there has been a large bias recently toward the service layer rather than a classic Windows DNA-ish business layer.   It's not been very clear what the differences are, I admit (what's the difference between an interface and a contract again ).   But at the same time, I think there is movement, especially in larger enterprise apps, away from objects representing application entities toward a more flexible container approach.   Even if classes are used, they generally inherit from a framework-resident type rather than another entity object.

  There are several big forces behind the rise of service layers.   First and foremost is that people first tried exposing business objects directly as web services and quickly found out that caller wanted more flexibility and that business processes are fluid.   The service layer became the place where you re-sequence the application component execution to match the business intention(s) implied by the message.   But to do that, you often have to de-serialize the message payload to object instances, which, to reiterate, is likely not a 1:1 operation.   That’s a lot of work and I think people find themselves writing reams of code getting and setting object properties to/from various message formats.   To add salt to the wound, they often do it all again to “serialize” data to SQL Server in the data tier.   Also, business objects themselves might not serialize to message formats that are usable by consumers – either because of type compatibility (which is why XML web services are used) or semantic usefulness – outside the application, so I think fewer people are directly exposing them.

  One other issue with business objects, as typically built, is that they wind up representing an instance of data for a single context and for a very narrow business intent.   It's convenient to think that when you get a sales order and then save that sales order that both FetchOrder() and SaveOrder() emit/consume the same type.   But in the real-world this is a minority case.   The fact is that the fields you can see vs. those you can actually change are VERY different.   The *behavior* of the data is controlled by policies that ought not be embodied in the business object code itself.   You might be allowed to pass the same sales order object back to the system for convenience, but there is probably a ton of code behind the scenes ensuring, for example, that you don't change the customer ID for a booked order.   Also and more mundanely, business objects tend to get polluted with fields from other entities stuffed in to avoid round trips to get descriptions of related records.

  So, I see movement (OK, maybe it's just me) to come up with a better way to promote (1) looser coupling between message payloads and the applications code, (2) looser coupling between the code and the database, and (3) a deterministic transform that relates the data domain to the message format.   It's a rethink about what I’ve been calling  the "primary colors" of a modern service-oriented app (not service-oriented arch, BTW): data, message, and behavior (code).

   

  
  
  

• Frens

  Hi Bobby,
  
  I would suggest you take a look at Jimmy Nilsonn's excellent book on Domain Driven Design Applying Domain-Driven Design and Patterns: With Examples in C# and .NET. He takes you through his train of thoughts to achieve a design where Entities are effectively decoupled from any framework concerns like persistence or data access.
  
  
  Simon Laroche
  
  
  

• Rtalan

  In my opinion you have severall options to do this:

  • You could use a messaging framework in your application to pass the objects from one layer to another. You could also use a plugin framework variation
  • You could attach the layers together by referencing Class A in Class B (in other words Class A is a property of Class B). This way Class B is aware of Class A and can call methods from Class A. For traffic the other way. Class B could attach to events Exposed in Class A.
  • You could split the layers in an 'upstream' and 'downstream'. Every class in the upstream is aware of the upstream classes in the layer above and the oposit for the downstream classes.

  Hope this helpt you. If you need more info, just ask away.

  
  
• Passing Business Objects through tiers?