DTO, Business Objects and architectural layers design

Question

Hi everybody,
What would prevent one from using Business objects (properties + getters/setters and bevaviour related to a business entity) thru all tiers of a J2EE Web application ?
Example : DAO layer populates BO properties, Business layer uses BO behaviour , web layer stores BO in some scope (request,session,...) for view presentation of the BO properties.
Compared to a DTO/VO (only properties, no behaviour) solution :
- If the application is distributed the BO solution adds serialization overhead (possibl performance bottlenecks) if BO's are large objects.
- If there is requirements for clustering , storing large BO's in session adds session replication overhead.
- BO solution breaks layer isolation , but practically speaking what could be the consequences of it ?
- Some BO properties need formatting for text deiting by the views and cannot be displayed as is.
- BO solution is a more OO approach than using only data objects
What other arguments can you think of ?

Answer 1

"Session" data applies to the session. Thus when I
order a book and it is added to my shopping cart the
session data might be used to store that information.
But that data in of itself is not a "business
s object". It is, by definition, session data.Ok conceptually speaking it is session data, but from
a technical point of view you need an Object instance
of some sort to hold that data.No actually you don't.
There are a number of ways to maintain session data. With tradeoffs between each.
What I was talking about (which does not mean I think
It is a good idea...) is using the BO properties for
holding that data and storing the BO instance(s) in
the session.
And I still don't see that this is a "Business Object". No more so than a security key is a "Business Object".
The best term is session data and you might have different groupings (data not behavior) within that.
Exactly what behavior do you envision?Any computational behaviour that uses the BO
properties and is needed to implement a use case.
This behaviour is used to calculate data that is not
persisted by the DAO as is but rather computed from
m other persisted data.
Give me an exact example.
For example it would be quite reasonable to have a DTO that represents a "rectangle" and that DTO would have a height and width and the DTO would have a method that return the area (multiplying the two data points.)
Conversely my previous example of the zipcode, the DTO should NOT have a method to validate that the zipcode exists although it could validate that it has the correct form (5/9 digits in the US.)
The problem is coupling. If the BO needs the
database layer (see the zipcode example above) then
the GUI layer is going to need the database layer is
well. Even though the GUI will never use the
database layer.I understand that this coupling applies to
distributed architectures where you package your
applications in different jars/wars/ears. In this
case If BO's ared used thru all layers, The GUI
(web) layer needs the data access layer jars even if
it will never use it.
This clearly adds coupling.
But in the case of a collocated application (a single
war) it does not change anything.
No. The point is not how the application is architected.
The point is that the GUI layer is then dependent on the database layer internals.
Consider another example, the DTO is produces a formatted xml string using a XML library. Now you need to create the database layer for the system. The database layer does not need the XML at all. And yet just to compile the database layer you are going to have to provide the XML library. This represents coupling that serves no purpose. And although in very small projects it might be convienent in larger projects coupling like that will cause problems and confusion.
And? Are you suggesting that the BO should do the
formatting?No I mean that DTO/VO's could have either text
formatting/editing methods or property types (e.g
String formatted property for a date) that facilitate
the work of the presentation layer. And most of the time that is going to be incorrect.
"Formatting" for a web page is likely to be different than for a printed report. And for a backend system it might need XML which is still a different format. Adding all of that to the DTO is not the way to do it. (In the same way that the database and gui code should not be intermixed.)
I would not put
any similar formatting behaviour in the BO. That's
why I consider this issue while comparing BO and
DTO's
- BO solution is a more OO approach than using only
data objects
No it isn't.
An object that prints itself is not more OO than one
that is printed.
I thought one of the purpose of OO programming was to
group behaviour and dataCertainly, but it doesn't mandate that one form of grouping is better than another. After if that was the sole concern then why not have just one object for the entire application - that is one way to "group" it.