DAOs X POJOs X FACADEs

[Andr� Salvati]

Hi,

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?

Thanks.



[ June 21, 2006: Message edited by: Andr� Salvati ]
[ June 21, 2006: Message edited by: Andr� Salvati ]

[Scott Selikoff]

It depends what you define as a dependency.

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 ]

[Andr� Salvati]

Scott,

I meant "dependency" as a calling dependency.

Thanks for your help.
[ June 24, 2006: Message edited by: Andr� Salvati ]

[Andr� Salvati]

I think this is a more architectural issue.

Could some administrator move this topic to SCEA forum!?

Thanks.

[Kartik Shah]

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.

[Andr� Salvati]

Just a example.

Imagine a Declaration which has Accounts. There is an attribute linking a Declaration to its Accounts (idAccount).

I was thinking of something like this for a Use Case named "Conclude Declaration's Accounts":

class FacadeDeclaration(){
 
...
 
public concludeAccounts(Long idDeclaration) {
 
  Declaration declarationPojo = declarationDAO.findById(idDeclaration);
  Iterator iter = declarationPojo.getAccounts.iterator();
  while (iter.hasNext()) {
idAccount = (Long) iter.next();
Account accountPojo = accountDAO.finbById(idAccount);
accountPojo.setState("concluded");
accoundDAO.update(accountPojo);
  }
}
 

This way:

FACADE -> DeclarationDAO (Find)
FACADE -> DeclarationPOJO
For each Account:
FACADE -> AccountDAO (Find)
FACADE -> AccountPOJO (state change)
FACADE -> AccountDAO (Update)


Are These your ideas?

I think it's necessary some behavior inside Pojo classes. For example: There could be several validations inside setState method of Pojo Account.
[ June 25, 2006: Message edited by: Andr� Salvati ]

[Kartik Shah]

Let me clarify.

DTOshould not possess any logic in it.

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

setName(String str){
   if(str != null && otherComplexBooleanCondition)
   {
      this.name = str;
   }
}

[Andr� Salvati]

Thanks.

I understand your point...

but we were talking about POJOs... are DTOs = POJOs?

[Kartik Shah]

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.

See the difference Here