I m new to all this so i have the following question.

Let’s say i have a domain model with POJOS and DAO objects for each of this pojos that do all the data access work using hibernate.

I want to ask if it would be bad practice to use a DAO object inside the getter of a collection preperty of the domain model class in order to populate this collection if its empty.

I understant that it is best for performance to initialize all the data is needed with hql (using eager fetching strategies for the collections we need) but maybe thats not possible every time or its not practical

No, no, absolutely no.

Do not mix layers. In a simple architecture with database+servlet container, your POJO's are your business objects: they contain the data model.

DAO,s, on the contrary, are the "mechanical" way to access data.
You should write your BO, application logic and DAO's in a way that, for example, if you'll decide to abandon Hibernate in the future, all you have to do is rewrite DAO's; not BO and application logic code (services/managers/process oriented b.o., call these with the name you prefer).

I suspect that you don't know "Open Session in View pattern": take a look at this.


Delta

Thanx for your replay :) Well to be honest the thing that bothers me with all this J2EE design patterns which some of them i have red too is that they are not so object oriented but they are more procedural in nature.

The concept of managers or commands or session beans that manipulate the DAO and work as cordinators along with the domain model in order to implement a part of the bussiness logic is in fact procedural.

The bussiness logic is splitted and one part is all the handling of DAOs that we need from a procedure and the other part are all the methods of the objects of the domain model.

For me the data layer is also a part of the bussiness logic and in some applications its the biggest part. For me it would be perfect to have only my domain model and all bussiness logic be implemented inside the methods of the objects even if they do data access.

But of course the details of this data access sould not be the consern of the domain model and thats why DAO exist. They hide the implementation details of the data access from the domain object. Using DAO objects even inside the domain model dont means that i cant replace the hibernate. The hibernate exist only inside the DAO object. The DAO object resive parameters, use hibernate and return pojos to the method of the domain model. If i dont want use hibernate then i rewrite the DAO to use JDBC for instance but the domain model is unchanged.

But on the other hand i m not so sure that this consept i have is rigth since they all use this design patterns rather than just a domain model and maybe there are many reasons for this that i dont know.

Long session is practical inside servlets fro lazy loading but inside Application Server ??

I think that in this case you can only work with "disconnected objects" and pass a copy of these objects between presentation layer and business logic layer... you know....DTO evil.

But I seriously doubt that if you mix dto/b.o. and dao/business logic you could really think to ejb and full enterprise approach.
For a such approach layers must be cleanly separated.

I had similar problems in the past, even not if in ejb architecture: at the end my need to mix layers was only poor design.

Delta