-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: Really need advice on good practice of JSF and Hibernate
PostPosted: Fri Apr 27, 2007 2:19 pm 
Newbie

Joined: Tue Jan 16, 2007 3:44 pm
Posts: 10
Hi there,

This is our first time to use Hibernate on our new project, but now we have some problem on the project organization. One of our co-workers insists to separate business layer (model and dao) and web beans into two projects. He put model and dao into a business layer project, and created a business.jar. Then put the jar into web layer project. I think putting them together is much better, like Caveat Emptor, although both of them work. If any experts can give some advice, we really appreciate it.

Best regards,

Sheng


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 27, 2007 4:01 pm 
Expert
Expert

Joined: Tue Jul 11, 2006 10:21 am
Posts: 457
Location: Columbus, Ohio
A couple thoughts,

There's nothing really wrong with separating the layers into different jars, at the least it enforces strict separation of concerns. However, unless you have distinct teams working on each piece of the project, it does tend to become a pain in the rear when everytime you have to make a change to the underlying model or dao, that you must propogate the resulting jar to your UI project(s). Frequently, newly discovered requirements in the UI layer necessitate a change in the business layer(s).

Saying that, in my current project, I actually do separate the three business layers (model, DAO, service) into an implementation jar and an interface jar. The implementation jar runs on the application server and exposes its methods via RMI. The UI projects that interact with the RMI services only need the interface jar (only the interfaces are included). But this particular design was necessary because I have several projects that interact with this RMI-based (and read-only) back end. Additionally, there are developers outside of my control who also use the exposed services. It is nice to be able to hide the implementation via only sending them the interfaces (with well formed, thorough javadocs).

If you are only using them for one project, though, I do not really see the need to separate the business layers into jars. As long as you always code to interfaces it's inherently pluggable already, why make it harder on yourself. :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 27, 2007 4:05 pm 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
If you use Hibernate and JSF, you want Seam: http://www.jboss.com/products/seam/

_________________
JAVA PERSISTENCE WITH HIBERNATE
http://jpwh.org
Get the book, training, and consulting for your Hibernate team.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 27, 2007 4:28 pm 
Newbie

Joined: Tue Jan 16, 2007 3:44 pm
Posts: 10
Hi Ananasi,

Thank you soooooo much for your excellent advice. That is really what I want to hear! I sincerely appreciate it.

Hi Christian,

Thank you very much for your advice too. In fact, I already practiced a project on Seam at home. However, my co-worker, Technical Lead, don't want to use the Seam. He told me: "Seam is used to combine two projects together, now we only work on one project. So we don't need Seam". ?????

Thanks again for your kind help.

Sheng


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.