I'm building a project with EJB (Stateless Sessions) and POJOS in my domain layer. I'm acessing DAOs directly from FACADEs when I want to build objects from repository. Arrows show dependeces between layers:
FACADE (Session Bean) -> DAO FACADE (Session Bean) -> POJO POJO -> DAO
Another solution would be put static methods inside my POJOS, as showed below. This way, I'd disappear with my FACADE -> DAO dependency.
FACADE (Session Bean) -> POJO POJO -> DAO
Which one is better? Which one do u like? Which one do u dislike? Why?
[ June 21, 2006: Message edited by: Andr� Salvati ] [ June 21, 2006: Message edited by: Andr� Salvati ]
Really, I would think your model would DAOs --> POJOs since POJOs have no database access code at all (else they would not be POJO's) therefore DAOs should use POJOs.
Generally no, I don't put static methods or any other kinds of methods in POJOs. Granted this means double the number of files but that's why you often use code generation tools to generate DAOs/POJO's together. As for Facades, in a service oriented architecture they are always on the top layer, and code inside the system should generally (although not always) avoid going through the facade layer for internal calls. [ June 21, 2006: Message edited by: Scott Selikoff ]
In terms of Layered approach you will follow Facade --> DAO --> POJO for populating POJO.
I would like to bring up couple of points: Every Class should have only one responsibility. Facade should have only one responsibility which is to act as single entry point to the application services. DAO should have responsibility to access DB and populate POJO POJO have only responsibility of representing data in object world.
It wouldnt make sense to include static method in POJO. I agree with scott's remark that then it wouldnt be POJO. Also it will violate principle of Single Responsibility. (i.e. one object should have only one reason to change or change in object should not cascade changes in other objects)
As for your question of reducing dependency Facade should depend on DAO (via interface)
POJO does not represent any behavior. (No logic in it, just member variables and getter/setter). In my opinion, you have to reduce dependency in terms of reducing dependency on behavior. Since POJO does not have any behavior, it is fine. In my opinion, you reduce dependency because you want to reduce cascading changes in classes due to change in one class. POJO does not represent any behavior. Vice Versa, Since it is required that POJO is accessed through all layers of application it is important that it should not have any behavior.
The reason to use lightweight DTO is because you are going to use it across the layers. (From your web layer to middle layer to backend layer). This object will be travel as method params or return params. May get serialized.
About your example above, I would still consider it a setter method. Not knowing what is inside setState method, I assume it is only setting the state to concluded.
However, there is certain logic is required to be performed while you change the state (set certain member variables) you may end up including that in POJO. Like
POJO = Plain old Java Object. POJO WikiPedia (To my knowledge, the term came into use to describe objects which does not extend any specific technology or frameworks. e.g. EJBs are not POJO because it they extend from EJB interfaces.)
DTO = POJO with Data Transfer Object Pattern applied to it.