2

I tried to learn on my own, but soon started to realize that by the end of endless books, I will know all the @Entity etc. low level stuff without ever understanding top level.

So my understanding is:

  1. We usually declare DAO interface where we define all the methods to perform on Domain Model.
  2. Secondly we write Domain Model to represent entity in Database.
  3. We write DAO implementation class which can use Hibernate, JPA , JDBC or whatever miracles we have out there and which implements our DAO interface.

(wiring up altogether with Spring)

My questions referring to points above:

We write single DAO interface per Domain Model? If we have cross-cuting behavior where participation involves more than one Domain Model we declare new pair DAO interface-implementation and call it accordingly? As example: "Customer orders from Stock, Stock checks whether Item is available -> confirms if it is" where would that go?

How Hibernate interacts with MVC? Are there any important aspects to be aware of?

In a book I noticed:

Overriding Equals and Hashcode

"In simple scenario, Hibernate is able to maintain entity equivalence without requiring any special changes to the domain objects themselves. However, if your application requires that you add entites to Java collections, such as java.util.Set, or you plan to work with detached entities, you will probably need to override the default equals() and hashCode() methods for your domain objects"

Maybe I don't understand it really well, what are detached entities? Are those the one we've taken out of Hibernate context - effectively just collections of classes?

What I want is safely to do Hibernate its work, then return me a Model which I would give to Servlet and which will delegate it to appropriate View. We extract that model by means of simple return from DAOimpl class methods or is it somewhat tricky?

If I am to do persistence tier without ORM framework, just with plain JDBC, what are my problems? I've heard that Hibernate has some smart session which handles concurrent requests, so what will happen with JDBC?

Where does business logic resides in? Is it DAOimpl classes?

I am sorry if some of my questions are mishaps, I appreciate any critic and correction.

Thank You.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
Aubergine
  • 5,862
  • 19
  • 66
  • 110

2 Answers2

2

We write single DAO interface per Domain Model? If we have cross-cuting behavior where participation involves more than one Domain Model we declare new pair DAO interface-implementation and call it accordingly? As example: "Customer orders from Stock, Stock checks whether Item is available -> confirms if it is" where would that go?

You could do that. A possilby simpler way would be to have a Service manage the DAO invocations. If you use Spring, you can define your transaction boundaries on the service methods, so all DAO methods will participate in the same transaction. So your DAOs stay specific to their respective models, and in theory are simpler. Keep in mind that when any DAO flushes the session, all changes get pushed to the database. So if you have a User and a Profile model, and they are mapped appropriately in hibernate, if you create an instance of each and call flush the session they will both get saved.

This approach is appealing because DAOs should do one thing -- perform persistence operations. If you start making complicated DAOs, you might be encapsulating the business requirements of your app in the persistence layer, which you don't want to do. Services are the place to order persistence operations to implement business requirements.

How Hibernate interacts with MVC? Are there any important aspects to be aware of?

MVC is a paradigm. Model View Controller. The intent is to define clear concerns in your application so individual components can stay focused on one thing. A Model object should not be telling a view how to render itself, for example. Hibernate is an ORM persistence implementation. Hibernate code is one way to save your model objects. MVC and hibernate have very little to do with each other, you can have MVC in an app and no Hibernate, or Hibernate in an app and no MVC.

Maybe I don't understand it really well, what are detached entities? Are those the one we've taken out of Hibernate context - effectively just collections of classes?

From the documentation "Detached - a detached instance is an object that has been persistent, but its Session has been closed."

Detached instances can still be saved later, but they need to be reassociated with the session.

If I am to do persistence tier without ORM framework, just with plain JDBC, what are my problems? I've heard that Hibernate has some smart session which handles concurrent requests, so what will happen with JDBC?

The main drawback is that you need to convert your jdbc results into objects, if your app uses objects to represent entities. You also need to write the sql. Using jdbc is not a bad idea. ORM is an options. JDBC is another option. You can also mix and match, but that can be complicated. Concurrent requests into your application should not be a concern of your persistence layer. Just make sure that your DAOs don't save any state (i.e. use static variables) and you should be fine.

Where does business logic resides in? Is it DAOimpl classes?

It's a combination of your domain model and your services. As already mentioned, if you need to save things in order, that can go in a service. If you have a requirement that some field should be restricted to some values, that could be in the model itself. It's NOT in DAOs -- those should just handle persistence.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
  • Thank You very much, can I use this object to pass it as a model to a view it is just an instance is it? Cat fritz = (Cat) sess.load(Cat.class, generatedId); – Aubergine Oct 04 '11 at 14:19
  • :-) I just asked specific question how to retrieve entity from Hibernate Session into a simple class instance. Cat fritz = (Cat) sess.load(Cat.class, generatedId); Cat fritz is not persistent and can be used for service and as a model is it? Sorry :-) – Aubergine Oct 04 '11 at 14:30
  • if you do that, you load a Cat instance. You can use it anywhere you want. If you change any values, then when you flush the session the cat will be saved. If the Cat becomes detached because the session is closed, it needs to be reattached. – hvgotcodes Oct 04 '11 at 14:34
  • I would want to do that when user makes changes, but when I just want to retrieve(ie just READ) a cat and pass to a user to see I don't really think that is a good idea, because if I want to do some adjustments to instance (ie how to display it) I don't really want accidentally to happen same to database entity. Can I just take it out from Hibernate context, so that it strictly java class instance with no additional behavior? – Aubergine Oct 04 '11 at 14:39
  • no, but you can define a DTO, like `CatDTO` which has the data but not the business logic -- it just contains the values you need. – hvgotcodes Oct 04 '11 at 14:43
1

I have removed the dao layer from my spring/hibernate web app - seemed unnecessary to me. In fact I can't imagine what they would consist of now. But this seems somewhat debatable.

For overriding equals and hashcode with hibernate I generally use the db generated auto id, again this is somewhat debatable. As long as you are aware that the id is only present after first persisting to db, there is not a problem.

Where does business logic resides in?

On your domain objects/hibernate entities - this is less controversial.

Community
  • 1
  • 1
NimChimpsky
  • 46,453
  • 60
  • 198
  • 311