Hello Saha,
I made my answer a new
thread for giving it a meaningfull topic name.
Originally posted by Saha Kumar:
In another post, you said you would not put a DAO and a BMP entity together in the same component?
Are you questioning what could be packed together in a component? In UML-2 this is much clearer now. Not just "the EJB". As you know you can specify an "artifacts" compartment for the name of the physical .jar including a deployment descriptor, so today you have a better chance to think in imaginable things. In UML-1 the whole component had been seen as physical.
Or are you questioning the role of entity-EJB vs. DAO? Both access the database. You design either an entity
EJB or a DAO for one given table [and sub-tables in 1.1]. I remember some people arguing to hide "technology specific" entity EJBs behind DAOs but still getting the benefits (caching, transactions) of the container.
Originally posted by Saha Kumar:
If the DAO was not to be used anywhere else, wouldn't this be considered dependent?
Also here:
Dependent of what? I try to guess your question:
For entity EJB:The EJB along with its deployment constructor is a pluggable, replacable,
deployable component, and needs to be due to be ruled by the container. It provides an interface, may depend on any prepackaged sub-jars but also may be totally independent from any other component because not having any
required interface.
For DAO: I can not remember having seen a single DAO forming a component, i.e. with an own deployment descriptor in the .jar of the DAO. That could make sense for ease of replacement by other DB-accessing/OR-mapping technologies like EJB-3 later - provided the DAO has a clear interface that later can just be realized by another component.
Thomas
[ May 12, 2006: Message edited by: Thomas Taeger ]