• Post Reply Bookmark Topic Watch Topic
  • New Topic

Value objects interaction in different tiers  RSS feed

 
Leon Pu
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have an application which separated to three tiers, presentation business and persistency.

In presentation tier, there are FormObjects to encapsulate the values on client pages.

In business tier, there are ValueObjects to encapsulate Domain Model or Business Object's attributes.

In persistency tier, there are persistency technology based ValueObjects.

During the interaction between presentation and business tier, presentation transforms FormObject to business tier's ValueObject, and then pass transformed ValueObject to business tier. So presentation only depends on business tier, there is no dependcy from business tier to presentation tier.

During the interaction between business and persistency tier, business tier transforms ValueObject to DataTransferObject. In persistency tier, it receives DataTransferObject, transform it to persistency technology known ValueObject, the return will also be DataTransferObject from persistency tier. So there is no direct dependency from persistency to business, DataTransferObject plays as middle and helps to reduce the remote invokes.

For the purpose of separate different tiers clearly, it seems worthy to do these kind of complex ValueObject transform and pass in different tiers. But for development effort, it seems too time-consuming to do it.

Is there any good idea for the ValueObject pass and tranform in different tiers?

Thanks in advance.


Best regards,
Leon
 
jiju ka
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is it a must for your application to have value Objects (beans) to represent each tier?

If the mappings changes often you can have your mappings stored in a file. May be xml file.

Mappings will have the relation ships between Presentation layer Beans and Business Layer Beans. Mapping can have relation ship between Business Layer and Persistence layer too.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I probably wouldn't introduce extra transformations until a compelling reason came up. For example the framework I use often builds an object from a database query, passes it through the business layer and right out to the presentation layer.

In a few cases the business layer adds value - computes derived fields, merges data from other sources, etc. Then it might transform to a new object or we might define a few fields that are not populated by the db.

In other cases we get data from multiple sources - databases, web services, mq-series, etc - and we transform them to look alike. We built the first one straight through and made that the "standard" format that we transform the others into.

I sometimes wonder if we're exposing too much of the data model to the presentation layer, but it hasn't done any harm so far and the idea of doubling the number of classes even if they have exactly the same fields just didn't fly.
 
Leon Pu
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have the same feeling that each tier has its own value objects definition is a kind of development effort waste. But if want to the application has clear architecture, it seems we have to do it.

For example, my application has four sub projects, ui (presentation) app (business) ds-management (persistence) ds-impl (persistence). Each sub project has own dependency to other projects and generates own jar. For sub projects dependency control, it's better to let sub-project-ui only depend on sub-project-app. Sub-project-app only depend on sub-project-management which makes it needn't to know who is the real implementation of ds-management. Sub-project-ds-impl only need to depend on sub-project-ds-management, it needn't know who invoke itself.

The interaction between different tiers is via value objects as arguments, so it seems each tier should has own value objects. Otherwise one sub project will jump to depend on another project.

If there is no better architecture design for the interaction between different tiers, I think the problem is that how to reduce the work of value object transformantion. Is there any good practice?

Originally posted by jiju ka:
Is it a must for your application to have value Objects (beans) to represent each tier?

If the mappings changes often you can have your mappings stored in a file. May be xml file.

Mappings will have the relation ships between Presentation layer Beans and Business Layer Beans. Mapping can have relation ship between Business Layer and Persistence layer too.


Could you introduce your solution of mapping value objects via xml? Maybe it's a choice for my case.
[ December 09, 2005: Message edited by: Leon Pu ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You emphasis on project dependencies is good. It would also work to think about compilation or deployment units rather than IDE projects. Can you deploy a new release of X without breaking Y? Can you change the interface between X & Y without also changing Y & Z?

I wonder if you could make the objects exposed by the business layer to the presentation layer extend the objects exposed by the persistence layer to the business layer. Presentation has no dependency on the presistence classes; the business can break that extends relationship if it needs to diverge to a new structure.

BTW: In my work life, the projects are vertical containing all the classes for one product or user group through all layers of the architecture. All the projects depend on one core project, but almost none depend on each other.
[ December 09, 2005: Message edited by: Stan James ]
 
Leon Pu
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
You emphasis on project dependencies is good. It would also work to think about compilation or deployment units rather than IDE projects. Can you deploy a new release of X without breaking Y? Can you change the interface between X & Y without also changing Y & Z?

I wonder if you could make the objects exposed by the business layer to the presentation layer extend the objects exposed by the persistence layer to the business layer. Presentation has no dependency on the presistence classes; the business can break that extends relationship if it needs to diverge to a new structure.

BTW: In my work life, the projects are vertical containing all the classes for one product or user group through all layers of the architecture. All the projects depend on one core project, but almost none depend on each other.

[ December 09, 2005: Message edited by: Stan James ]


Thank you for your reply, I have waited a long time to discuss with somebody.

For your example, it's possible to deploy a new X release without updating Y if there is no interface change. And if Y's interface change doesn't influence Z, it only needs to update X.

The value object extend solution seems not suitable in my case. I have a sub project ds-management who defines the persistence tier transaction and facade interface, also manages different persistence implementations. Since there will more than one persistence technology in the whole project, it's hard to let business tier's value object extend persistence tier's.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
more than one persistence technology in the whole project


If the different persistence technologies expose different object models, that's a pretty good motivation for some translation into your own model of data objects, maybe in an adapter layer in between them.

Our framework exposes identical data objects and nearly identical APIs for databases and MQ-Series. We went to some effort to make Web Services expose the same kind of objects. The business services and their clients see consistent data objects regardless of the source.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!