The Value Object is immutable whereas an Data Transfer Object is not. That is the primary difference.
The pragmatic use of an entity bean is for rapid development, particularly where the data structure has some uncertainty. In complex systems, where no precursor exists, you sometimes find yourself in new territory where the subject matter expert has overlooked or forgotten a key requirement that communicates the need for additional representations in the data structure. Here, the entity bean is invaluable in speeding up the development process since you do not need to do as much plumbing to get basic reads and writes working, particularly to ensure transactional atomicity and the like. However, an entity bean has shortcomings. EJB-QL is not as flexible as constructed SQL so for some complex finders you need to resort to a DAO implementation - for example, the pure J2EE spec as it currently stands does not support ordering. Also, there are certain cases where you want a "light" retrieval such as when the table contains BLOBs, and for speed sometimes you want to be able to retrieve a partial entity and ignore the BLOB field. Entity beans can be inefficient. So a DAO is sometimes the answer as it gives you total control over operational efficiency (at the loss of development speed). You can hide the implementation behind a session facade so the "client" is protected from changes between an entity or a DAO implementation - in keeping with the pattern philosophy of encapsulating change. As you tune your application, you can refactor and replace the entity bean operations, either in part or fully, depending on the architect's determined performance requirements and the amount of time you have. Pragmatically, and in line with Iterative and Incremental Development practices, you probably will start with entities, and as more complex retrievals arise from finer grain use-cases in successive iterations, you will gradually replace at least certain entity operations with more efficient DAO implementations. XDoclet can help with this gradual change process as it generates and updates the Value Object based on changes with entity bean. As much as possible, try to add any DAO refinements when the data structure is more stable as it will save you wasted effort in maintaining the DAO operations while the data representation is still changing - you'll have to negotiate with the user/client on this and sometimes it helps to explain things to them (sometimes slowly and carefully). Hope that helps, and of course, MHO. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3830181#3830181 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3830181 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
