DAO Layering; DAO/DAO, DAO/EJB, etc.
We have a case where we are designing a set of EJBs that will play the role of Value Assembly Objects. Our Business Objects are in DBs that have DAOs layed below an EJB layer. When we construct the Value Assembly Object (VAO) as a Stateless Session Bean, we have the following choices:
* Have the VAO EJB assemble its information from the existing EJB tier (some of these are lower level VAO EJBs).
* Create a DAO within the VAO EJB that instantiates/interacts with the lower level DAOs directly.
* Create a DAO within the VAO EJB that uses a mix of lower level DAOs and lower level VAO EJBs.
Although the DAOs were documented as saying they obtain information from "any" data source, the documentation never discussed the pros/cons of having the DAOs accessing information from EJBs versus the EIS data sources. Should DAOs be allowed to be clients of EJBs?
In some cases, we have VAO EJBs that do value-added assembly over their DAOs. Their DAOs cannot be simply taken and assembled into a higher-level VAO EJB. In this case, should we allow a VAO's DAO to access the lower-level VAO EJB? or move that integration behavior up to the VAO EJB itself?
Should the VAO go through the fully encapsulated EJB layers or assemble the EJBs DAO objects into a single EJB? The data is very closely related and there is very little chance that they will be offered by different EIS data sources. Assembling them into a single EJB would eliminate the possible RMI marshalling that would take place between the layers.
A few words of discussion might be helpful in clearing up this muddy design area.
jim
[1661 byte] By [
bhc6849] at [2007-9-26 4:21:01]
> We have a case where we are designing a set of EJBs
> that will play the role of Value Assembly Objects. Our
> Business Objects are in DBs that have DAOs layed below
> an EJB layer. When we construct the Value Assembly
> Object (VAO) as a Stateless Session Bean, we have the
> following choices:
>
> * Have the VAO EJB assemble its information from the
> existing EJB tier (some of these are lower level VAO
> EJBs).
> * Create a DAO within the VAO EJB that
> instantiates/interacts with the lower level DAOs
> directly.
> * Create a DAO within the VAO EJB that uses a mix of
> lower level DAOs and lower level VAO EJBs.
>
> Although the DAOs were documented as saying they
> obtain information from "any" data source, the
> documentation never discussed the pros/cons of having
> the DAOs accessing information from EJBs versus the
> EIS data sources. Should DAOs be allowed to be clients
> of EJBs?
The pro-con is maintainability vs performance.
> In some cases, we have VAO EJBs that do value-added
> assembly over their DAOs. Their DAOs cannot be simply
> taken and assembled into a higher-level VAO EJB. In
> this case, should we allow a VAO's DAO to access the
> lower-level VAO EJB? or move that integration behavior
> up to the VAO EJB itself?
>
> Should the VAO go through the fully encapsulated EJB
> layers or assemble the EJBs DAO objects into a single
> EJB? The data is very closely related and there is
> very little chance that they will be offered by
> different EIS data sources. Assembling them into a
> single EJB would eliminate the possible RMI
> marshalling that would take place between the layers.
Use normal code reuse methodologies to eliminate this problem.
> A few words of discussion might be helpful in clearing
> up this muddy design area.
As a general rule, you should aim to decouple your various layers as much as possible, they should only communicate via their appropriate fascades.
The way you've described things, you've potentially doubled your RMI workload on the server. Which given that minimising inter-server (ejb) communication is probably the primary reason's for using Composite's of Value Object, kinda defeats the point.
