Johannes,
Sorry as I may disappoint you, but I do not respect the IoC pattern as
described like :
“Always expect to be called. If you ever need to call, never call
direct. Always ask the framework. The framework knows.”
My DAO are hard-wired too, I didn't manage to use Avalon as the learning
curve was awfully steep for me :(
What I tried to respect is the Dependency Injection concept as described
here :
http://neelzone.wordpress.com/2007/04/04/injection-and-inversion/#more-29
Flowscript creates the HS which I inject into my model with the
constructor. All my DAOs have a superclass storing this Session. Quite
basic way to do it, you seem to do the same in a more elegant way.
Your example of changing data access method from Hibernate to e.g. XML
data or Web Service is quite pertinent. I totally agree that this is
unlikely to happen.
Hibernate feature to switch database is the purpose of its use in my
project, as switching from MaxDB to MySQL will be performed in the
future. Although this will have a cost for sure (hello native SQL querys
here).
In short, having DAO hardwired to Hibernate/JDBC is imho definitly
justifiable in a small to medium size project. And I'm interested for
sure in your experience with this implementation ;)
Baptiste
Johannes Textor a écrit :
Hi Baptiste,
>> Being a newbie, I struggled quite a time on the model and finally used
Generic DAO like described here : http://www.hibernate.org/328.html
For sure having the FlowScript to open Hibernate Sessions is messy in
the MVC pattern, in your implementation are you using some
HibernateUtil-like class ?
Something like that. My DAOs inherit from a common superclass which
has a method "assertSession()" which opens a session and stores it in
the HTTPRequest, if it is not already there. Then by calling a method
getSssion(), you retrieve the Hibernate session from the current
HTTPRequest. Sessions are closed as usual by a Servlet Filter.
>> I don't know your DAO implementation, but is having every DAO wrapping
the calls to Hibernate (i.e. Session handling) some sort of violation of
Inversion of Control pattern ?
- Not very sure that this question is justified !
You are right. Most people these days use DAO along with IOC, but I
think this is not automatically necessary. If I get it right, IOC has
the purpose of being able to substitute Hibernate with another data
access method. But, Hibernate itself already provides the ability to
switch across *databases*, thus leaving you only with the assumption
that your data is stored in a database, and not, e.g., accessed via a
web service. Most projects I worked on are tied to databases anyway
(even switching from MySQL to something else is mostly highly
unlikely), so I preferred to keep things simple and hardwired my DAOs
to Hibernate. You might argue if this is a beautiful architecture, but
then there are many people out there who hardwire their DAOs even to
JDBC.
Since you seem to be using DAO/IOC: how do you implement the IOC part?
are you using Spring, Avalon, or some similar framework ?
Regards,
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
