Layered Applications and Business Entities

[ChrisPlatt]

Does anyone have any advice on how to seperate out Business Entity Data (i.e. common data that will be passed between layers in the application) from the Business Rules relating to the Business Entities?

I am assuming this the correct way of structuring an application so you do not have to pass around business rules along with and object data.

My current application has a series of Business Entity Data classes and a parallel set of Business Rule classes into which I pass a parameter of the Business Entity Data class.

Hope this makes sense...

 

[EdwardJS024]

Hi Chris,
it sounds like there is something seriously wrong with your current design. Objects are objects, they encapsulate their data and rules from the outside world.

You should never try to extract out the data from an object and place it into it's own entity.

Seems like you have pulled the data and rules of an object into seperate things. You have literally disected what an object is.

>>Tell me if this makes sense to you:
Would you buy a Car and then pull out the parts and place them into containers in your backyard only to reassemble them into the car when you need to drive down to KMart?

Obviously it makes sense to let the object encapsulate and maintain its internal state and rules as is.

Have a look at this article I wrote a while back:

"Conceptualizing an Object"

http://softwaretheory.blogspot.com/

It discusses a metaphoric view of an object and it's life-cycle in a system.

 

[ChrisPlatt]

Hi Edward,

I am current involved in the design of a distributed web application and am trying to get my head around how is best to layer the application.

I see what you're saying but am still left with the question of how to represent an object/business entity across layers. Would you suggest passing instances of classes between the layers?

I have been looking at the Microsoft(!) Duwamish 7 example in C# (

http://msdn.microsoft.com/library/d...7/html/vtoritechnologiesusedinduwamish70.asp)

and got my original ideas from the fact that they represent there core business entities as typed datasets. The application of any business rules are performed by parallel classes in the business rules layer.

Any suggestions would be greatly appreciated.

Thanks for your help...

 

[EdwardJS024]

First, I would not trust every or anything that is preached by microsoft in terms of the oo paradigm. They are new jacks to the OO game and prior to .NET they were mostly procedural, just look at MFC..disgusting. Some of their articles are written by knowledegable experts while others are ignorant to Principals. MS do what they always do best, they borrow ideas and invent new priopritary ways of doing things.

It's irnoic that I am a C#/.NET programmer though..:0)

Anyway, what do you mean by passing an entity across layers? When you speak of layers are you meaning computers in a distributed architecture or do you mean they architectural layer boundries within a single application?

 

[chiph]

It sounds like you're trying to create Data Transfer Objects -- an object that contains the data for an entity, but few (if any) methods that act on the data. They're used for transferring between layers, typically.

A book you should own is Martin Fowler's Patterns of Enterprise Application Architecture. It's expensive, but worth it.

Chip H.


____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[stevexff]

I'd second chiph's recommendation of PEAA. Along with Deepak Alur's Core J2EE Patterns (examples all in Java, obviously), but the principles hold good whatever OO language you use.

The idea of the DTO is that making calls to another layer (possibly over the wire) is expensive, so you don't want a chatty application that keeps making calls to the business layer. You also don't want to replicate the BO layer in the presentation layer, as that defeats the object of layering in the first place.

The DTO is a simple object with values, getters, and setters, that needs to be deployed in both layers. On the server side, you have an Assembler class that interrogates a business object, and creates the DTO. The DTO gets serialised, sent across to the client layer, where the client displays it, changes it, or whatever. The changes get sent back, either in the same DTO, or a different one, and the Assembler uses the DTO to update the business object.

But the business rules stay in the business object - if the updates are illegal, then the BO raises an error.

 

[ChrisPlatt]

It is the passing of entities across architectural layer boundaries within a single application that I am referring to.

I'm gonna have a look at the Book - Patterns of Enterprise Application Architecture, to get some more ideas.

Any other books anyone would recommend on this topic?

Any suggestions are more than welcome...

 

[EdwardJS024]

Why not just pass references to the entity/Value objects around?

For example, take these layers:

------------
UI
------------
Application
------------
Domain
------------
Infasctructure
------------



Lets say the User needs to view a Policy on screen, obviously the UI needs to get a reference to a policy entity in order to build it's interface. How does the UI get that reference?

The UI can delegate to the application layer, asking the ShowPolicyCommand object to find a Policy. ShowPolicyCommand delegates to the layers below(domain) in finding a policy, which then bubbles back up the stack to the UI.

The UI can then bind one of it's controls to the reference object, hence displaying onscreen.

I make it sound simpler than it is. There's a bit of CRUD work involved, Repositories, DAL's etc, but that's beyond the scope of this post.

-Edward JS

 

[ChrisPlatt]

Would this approach have to change dramatically in a distributed scenario?

In my original design I envisaged the usage of DTO's to ensure that no layer other than the model/domain layer would have knowledge of the underlying business entities...

Any useful documentation on these design approaches in .NET?

Thanks...

 

[chiph]

It is the passing of entities across architectural layer boundaries within a single application that I am referring to.

A lot depends on how rigorous you want to be, plus whether the layers are local or remote. If the next layer is local, then a simple call via an Interface will probably be good enough. However, if you've a ton of parameters, then a DTO will be very helpful, just from a "maintain my sanity" perspective.

Any useful documentation on these design approaches in .NET?

Pretty much the same as Java. Only big difference is you can have ref and out parameters, unlike Java with it's in-only parameters to methods.

Chip H.


____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[ChrisPlatt]

Ok guys...let me clarify my understanding here:

My app is layered and distributed as follows:

UI/Consumer Layer (Physical Tier 1 - Web Server)
-----------------------|.NET Remoting|-------------------
Facade/Application Layer (Physical Tier 2 - App Server)
---------------------------------------------------------
Model/Domain Layer (Physical Tier 2 - App Server)
---------------------------------------------------------
Data Access Layer (Physical Tier 2 - App Server)
---------------------------------------------------------
Database Layer (Physical Tier 3 - Database Server)

Would it be best practise to code the UI layer to utilise a series of custom DTO classes or to pass around the business entities from my Model/Domain Layer as suggested by Edward (i.e. a Policy class instance containing all its data and methods - hope I understood you ok there Edward!).

I'm really keen to get a thourough understanding of this topic so all your help is much appreciated.

Chris

 

[chiph]

If you use the classes from the model/domain layer, that couples your GUI to that code. If this isn't a problem for you, then that'll be fine.

Imagine if the GUI was changed to something like a PDA or web interface -- how would that affect that choice?

Chip H.


____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first