Search code examples
javadesign-patternsjavabeansdaodto

Entity Bean and Data Access Object Pattern

I am having a few issue in understanding the DAO design pattern Here.

My confusion lies on two points :

  1. In the "problem" section of the website, the entity beans which are referred to...are they solely for web technologies? I believe I am using the above design pattern with a pure java program, where I use DTO and DAO using generics to represent several types (Contacts, events, jobs, academics). Each have their own implementation of a super-class BASEDAO, which manages all the sql statements to the database and its connectivity.

Now, I am not sure whether my DTOs to represent contact, event, job would be classed as ENTITY BEAN or not. Would my DTO come under the business component the above site speaks of?

  1. Towards the end of the Problem section of the website, it speaks of t*ight coupling between the components and the data source implementation*. I am not sure what this means. Would anyone be kind enough to elaborate or show me a simple example with Java code with the
Solution

  • Now, Entity Beans are a Java EE concept, you can build DAO without them as well, and many do. (e.g. Hibernate)

    To answer your 2nd Q, tight coupling happens when you write your custom code to manage the DB connections, queries and such, without using a DAO. If you use DAO, and use a datasource, all your business logic is safe when you change your data store and or source, which can be handled with minimal change in config script, instead of writing new code all over again in the absence of DAO.