Originally posted by Ernest Lee: DAOs allow you to control the access of data from resources and switch to CMP when the tools have better support, but this means you must write and maintain the SQL code.
Hi Ernest, I agree with you on that the main drawback of DAO and BMPs is that you need to maintain the SQL code (unless you have a tool that automatically maintains it for you!). But sometimes they are necessary due to CMP limitations (ie they do not read BLOB/CLOB fields, or sometimes they do too many unnecessary database accessed) DAO and entity beans (both BMP and CMP) are very different, so you will have to be very carefull if you start using DAO and then want to switch to entity beans in the future (there are some patterns for this issue that can help). I would say that the main difference between DAO and entity beans is that DAO is light-weight whereas entity beans are heavy-weight. While using DAO is more efficient, you don't have the features of EJBs. Eduard
DAO and entity beans (both BMP and CMP) are very different, so you will have to be very carefull if you start using DAO and then want to switch to entity beans in the future (there are some patterns for this issue that can help).
It seems as if you are saying that one can use either DAO or Entity Beans but not both. Most people that use BMP also utilize DAO to manage the persistance. Personally I don't see much benefit of BMP. If you are just going to wrap a Session Facade around it anyways then why not go with straight DAO? At least with CMP you get the persistance for free. [ October 15, 2002: Message edited by: Chris Mathews ]
Joined: Aug 20, 2001
Actually, the above sentence is quoted from "SEJA study guide"... I can't really understand it at all... i feel quite disappointed with the GUIDE.
Joined: May 12, 2002
Chris, I agree with you, you can use DAOs for BMPs (and I think it is a good practice for those developing BMPs!). However, what I meant is that you have to be careful from the database-layer client point of view (ie session beans). You don’t use DAOs in the same way as entity beans. For example, to use a DAO you just need to create a simple object and start using it (simple, isn’t it). However, if you want to use entity beans you need to do a little bit more work, such as lookup home interface, narrow it down and get the remote interface. My point was that if you want to leave the option open for switching from DAOs to entity beans in the future (or viceversa), you’ll have to be careful how you access the database-layer from session beans (otherwise you’ll get stuck with one technology) Finally, I also think the future of entity beans is CMP. However, I think it is still an evolving technology that it hasn’t got there just yet. For example, if your database use BLOB/CLOBs, there is no way of accessing them through CMPs. Or sometimes they cannot handle complex entities (ie involving several tables). CMP 2.0 attempts to fix this problem, but those unlucky developers working with Websphere can only cry and watch.
Is that BMP with DAO instead of Session Facade with DAO is to promote better component-based developement? Steve.
Joined: Oct 15, 2002
So, to ease the switching to CMP later, we should now use BMP with DAO instead of DAO alone. So that the caller has the very similar interface on accessing the persistence logic. Am I right? Thx. and Regards. Steve.
Originally posted by Steve Wong: Is that BMP with DAO instead of Session Facade with DAO is to promote better component-based developement? Steve.
I think the Session Fa�ade pattern is meant to be used only for the business layer (ie for clients accessing session beans) rather than session beans accessing the database layer (as per Floyd Marinescu’s book – “EJB Design Patterns”, which by the way I think it is a master piece). The idea behind this is that application clients (ie JSPs, Action classes from struts framework, java applications… should not know the guts of the application, thus accessing it via a Fa�ade makes sense. However, I don’t think the same applies for session beans accessing entity beans. Anyway, I think the decisions an architect should take when designing the database layer are as following: 1) Decide whether to use DAO (light-weight) or entity beans (heavy-weight) 2) If you want to use entity beans, decide whether to use CMP or BMP 3) If you want to use BMPs, decide whether you want to put the SQL statements in the EJB, or move them outside, and I think using DAO for the latter is a good option. There is a very good discussion on whether you should use DAOs or entity beans in Floyd’s book (chapter 8). By the way, you can get it online at www.theserverside.com. Eduard
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com