Hibernate, DAO pattern and tree hierarchy

Hi all,
I use Hibernate for a short period of time and now I'm facing a complex problem . I try figure it out what is the best practice for the following scenario:
I have the following classes: Department, Team, Position, all of them inherited from a Entity class even there is almost no difference between them. But I wanted different classes for different entities.
I try to create a tree hierachy, each object is with all others in a bidirectional one-to-many relationship. For example a Department can have Teams and Positions as children and a Position can have Departments and Teams as children.
I created the mapping files and I don't know how to create all necessary methods without duplicating the code.
Questions:
1. Do I need a DAO pattern implemented for this design?
2. Can you recomend some documentation or ideas that will help me find out what is the best approach in this case?
Thanks

Write the DAO for the class that is the root of the tree. Sounds like it should be DepartmentDao.
I don't know of much better documentation than the Hibernate docs. Check their forum, too.
%

Similar Messages

DAO Pattern and the ServiceLocator

I have been developing a lightweight framework for working with AIR and the SQL API. This framework has no dependencies on Cairngorm however it is built around a typical DAO implementation.
While developing this I considered how it should be integrated with Cairngorm, which lead me to wonder if a simple DAO marker interface which could be retrieved from the ServiceLocator (and cast to the correct abstraction by a business delegate) would not be all that is needed to have a rather flexible service layer in Cairngorm?
For example, consider the following pseudo code which is what I would imagine a business delegate to look like:
class FooDelegate {
protected fooDAO:IFooDAO;
public FooDelegate(responder:IResponder) {
fooDAO = ServiceLocator.getinstance().getDAO(Service.FOODAO) as IFooDAO;
fooDAO.addResponder( responder );
public getFoo() void {
fooDAO.getFoo();
public addFoo(foo:IFoo) {
fooDAO.addFoo(foo);
public deleteFoo(foo:IFoo) {
fooDAO.deleteFoo(foo);
As you can see the delegate would cast the dao to the correct abstraction and then just wrap the DAOs API (somewhat similar to an Assembler in LCDS).
A custom DAO interface would extend the DAO marker interface so that the ServiceLocator could find it:
interface IFooDAO extends IDAO
getFoo() void;
addFoo(foo:IFoo);
deleteFoo(foo:IFoo);
Service.mxml would define an instance of the dao as an abstraction and then call a factory to get the appropriate implementation:
public fooDAO:IFooDAO = DAOFactory.getDAO("foo");
I see much potential in this type of implementation as it would allow services to be swaped out with different implementations via a config or with an IoC implementation etc, thus allowing the services themselves to be completely transparent to client code.
I wanted to see if anyone had any thoughts on this as well?
Best,
Eric

Thanks, duffymo, that makes sense. However ... having read through numerous threads in which you voice your opinion of the DAO World According to Sun, I'd be interested to know your thoughts on the following ...
Basically, I'm in the process of proposing an enterprise system architecture, which will use DAO as the primary persistence abstraction, and DAO + JPA in the particular case of persistence to a RDBMS. In doing so, I'd like to illustrate the various elements of the DAO pattern, a la the standard class diagram that relates BusinessObject / DataAccessObject / DataSource / TransferObject (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html). With reference to this model, I know that you have a view on the concept of TransferObject (aka ValueObject?) - how would you depict the DAO pattern in its most generic form? Or is the concept of a generic DAO pattern compromised by the specific implementation that is used (in this case JPA)?

DAO pattern and Java Persistence API

Hi
This is a question for anyone who might be familiar with the standard DAO design pattern and the Java Persistence API (JPA - part of EJB3). I'm new to this technology, so apologies for any terminology aberrations.
I am developing the overall architecture for an enterprise system. I intend to use the DAO pattern as the conceptual basis for all data access - this data will reside in a number of forms (e.g. RDBMS, flat file). In the specific case of the RDBMS, I intend to use JPA. My understanding of JPA is that it does/can support the DAO concept, but I'm struggling to get my head around how the two ideas (can be made to) relate to each other.
For example, the DAO pattern is all about how business objects, data access objects, data transfer objects, data sources, etc relate to each other; JPA is all about entities and persistence units/contexts relate to each other. Further, JPA uses ORM, which is not a DAO concept.
So, to summarise - can DAO and JPA work together and if so how?
Thanks
P.S. Please let me know if you think this topic would be more visible in another forum (e.g. EJB).

Thanks, duffymo, that makes sense. However ... having read through numerous threads in which you voice your opinion of the DAO World According to Sun, I'd be interested to know your thoughts on the following ...
Basically, I'm in the process of proposing an enterprise system architecture, which will use DAO as the primary persistence abstraction, and DAO + JPA in the particular case of persistence to a RDBMS. In doing so, I'd like to illustrate the various elements of the DAO pattern, a la the standard class diagram that relates BusinessObject / DataAccessObject / DataSource / TransferObject (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html). With reference to this model, I know that you have a view on the concept of TransferObject (aka ValueObject?) - how would you depict the DAO pattern in its most generic form? Or is the concept of a generic DAO pattern compromised by the specific implementation that is used (in this case JPA)?

DAO classes and Hibernate

hi all
need help.
i have one dought where is used DAO classes and where is
used Hibernate.i think both r used for data base access ,but why we are
used both.
thanks in advence.

i have one dought where is used DAO classes and where is
used Hibernate.Awesome, we got doubt misused AND misspelled!
i think both r used for data base accesscorrect!
but why we are used both.DAO is a design pattern (concept) and Hibernate is a product (code implementation).
Hibernate is a DAO implementation. That said, you don't need both, in fact you don't need either.

DAO pattern Value Objects and Data Streams

Suppose we have a PersonVO (java bean) with simple attributes i.e. first and last name then the DAO is quite simple and clients of the DAO layer pass VO back and forth (really cleanly).
But it is a different story if a person has a picture. If the picture is small then we
could define a field that is simple an array of bytes i.e. byte pic[], and would work ,
but will not scale if our pic becomes too large or there are lots of persons.
How can streams be used in this case ? (without dao code leaking into the client layer) and does this break the DAO pattern ?

I can picture not saving the image bytes themselves
but a link to a JPG or GIF on the file system.And how would that be guarenteed on a cluster? Or even per OS?
Putting streams into a database like that can choke
performance. Can't do WHERE clauses on byte
streams.For example in PostgreSQL:
CREATE TABLE images (
name VARCHAR(32) NOT NULL,
image bytea NOT NULL,
imagetype VARCHAR(4),
CONSTRAINT image_pk PRIMARY KEY (name)
);After retrieving the image into a byte[] you can either
- directly serve it to the client (browser) over HTTP through a servlet
(don't forget to set your content type through HttpServletResponse.setContentType())
- convert the byte[] to a java.awt.image.BufferedImage using javax.imageio.ImageIO.read(byte[]), and ofcourse do everything you want (including transformations) from there.
- What ever you can think off.
Now if you're passing that VO to a JSP, the link to
the image on the server file system fits nicely into
the <img> tag and Bob's your uncle.But this will still not be guarenteed to work on a cluster, across platforms, etc.
10 % 0
java.lang.ArithmeticException: / by zero;-)

DAO Pattern Confusion

Hello,
Have started developing with J2EE recently, moving up from J2SE. With regards to persistance of data to a database I have been looking at the DAO pattern. I am a little confused about this pattern, so I hope someone may be able to clear a few things up.
As I understand it the Transfer Object (TO) can be a simple java bean with getter and setter methods.
The DAO can only have four methods, create, read, update and delete. I am a little confused here, because as I see it, we can only have these four methods to read/write from/to the TO.
Isn't this very limiting? For example, the update statement of the DAO will have to have a TO which has already been populated, for this to occur an already populated TO has to be generated (a read on the DAO) and then the required values changed via the get/set methods of the TO. Then a method of the DAO has to be called to persist this data to the database.
This would cause difficulties if we wanted to implement optimistic locking for example, where we wanted to check if a row had been changed before commiting the change (to prevent lost updates).
Would it not be better to have many methods in the DAO, and a customer TO for each one? E.g. methods such as:
TO to = new TO();
to.setState("new");
to.setWhere("old");
dao.updateState(TO to)
Such a design would let us update the state of a row in the database to "new" where the state previously was "old" and hence be a basic implementation of optimistic locking.
Or are we completely missing the point!
Many thanks,

>>
IMO, this model is broken. TO's, as traditionally
implemented, are read-write. In most cases, it is
easier to code a TO as read-only. Provideinstance
values in the constructor and then expose onlygetter
methods. One possible implementation is to havethe
DAO and the TO (or preferably model object) in the
same package. Make the constructor of the TO
protected (or package private). Then, the DAO can
initialize values from the persistent store, but
users of the TO will only be able to read thevalues
retrieved. If this model becomes limiting, you
should realize that you are now allowing mutator
methods. IMO, your TO should now be afully-fledged
domain model object.
I disagree. And apparently others do as well because
your model is the way that J2EE first represented
DTOs (as a "Value Object").
I will refer you to Bloch, et. al. Immutable objects are easier to code and to test.
I suppose my reason for this would be that most of
the work in other layers involves sending mutated
data back. With your pattern this requires that the
user, every single time, create a new object, copy
the old data to the new, and then send the new object
back.
You are asserting the 'new' keyword is onerous?
Extra work with no gain.
I agree. There is an ever so slight overhead to creating a new, immutable object. However, limiting the possible states of an object, by definition, lowers its entropy and hence the possibilities one needs to test.
The DAO can only have four methods, create,read,
update and delete. I am a little confused here,
because as I see it, we can only have thesefour
methods to read/write from/to the TO.
This is roughly what a database allows. However,
what of commonly used parent-child or foreign-key
relationships? You may retrieve an account holder
and his/her present balance 90% of the time inyour
system. Do you want two separate TO's and DAO's
here? Or is this a case where a DAO can constructa
graph of objects in memory as an optimization?
Yes. Issuing a single SQL query to fetch a parent child relationship is more efficient than fetching foreign keys in a parent table and querying for each child. Maybe we are in fact on the same page, maybe not. But I am referring to releationships such as many-to-many that pose difficulties to O/R mappers. The same would hold true for a design where each table row corresponds to an object.
There are several other J2EE patterns for complex
relationships.
I am not sure I have ever encountered a need for
those though.
Other than chaining various Collection classes, neither have I. However, a fairly rich set of relationships (hierarchical, sequential, dependent, etc.) can be constructed from these.
>>
This would cause difficulties if we wanted to
implement optimistic locking for example, wherewe
wanted to check if a row had been changed before
commiting the change (to prevent lost updates).
I would not implement this myself. As Duffy has
alluded to, Hibernate and other O/R mapping
technologies maintain the state of an object andthe
state when it was retrieved, allowing theframework
to update only modified fields when needed.
Interesting.One of the best benefits that Hibernate offers out of the box, that and lazy loading. Though like all things, these too can be abused.
- Saish

How can I create a tree hierarchy in Adobe Flash with WD Java?

Hello!
I've started to learning RIAs based on WD Java and Adobe Flash. Now I need to create application with tree hierarchy. Nodes of hierarchy must be able to collapse and expand. Hierarchy must looks like in https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/a0c91fc0-932d-2c10-4ca7-f5774950c8e3 (first section)
Does anybody know where I can get a tutorial for such hierarhies or which control element I have use?
regards, Lev

well, Network UI should be used.

How to Create and External Hierarchy and group values of IO in node

Good morning
BI 7:
Please give me guidance on the following?
I need to either to restrict a characteristic in a query to more than 800 values OR exclude values where it contains the pattern 'Z7' and 'Z8'. There are thousands of values which contains the pattern and they are not listed in such a way that I can exclude them as a value range, thus I would have to include all the values I want into the restriction, which is more than 800. An error displays when I check the query:
""In the structural component Warranty Damage Code, characteristic ZWR_DMGC is restricted to 838 values. This number is very large and will probably meet with technical limitations""
The proposed solution is:
""Create an external hierarchy for characteristic ZWR_DMGC and group the 838 values in a hierarchy node. You can then work with the node instead of the 838 individual values.
Alternatively, you can define a corresponding navigation attribute for ZWR_DMGC""
I know where to create the hierarchy, but I am confused how to only include the values of the applicable IO where pattern contains 'Z7' and 'Z8'.......??
The following are some of the steps proposed in a related thread, but I am loosing it at step 7.
5. Confirm your entries. The Maintain Hierarchy screen appears. You can define the structure of a hierarchy here. ok
6. To create a hierarchy node, you first need to choose an insertion mode: Insert as First Child or Insert As Next Neighbor (see Hierarchy Editing Functions). I selected first child
7. Choose the type of node you want to create: Text Node, Characteristic Node, <Hierarchy Basic Characteristic Node> or Interval (see Hierarchy Nodes) *this is where I am lost, which should I select to list values with pattern ' *Z7' and ' Z8' in a node or two
8. Repeat this procedure until the hierarchy structure has been set. For more information, see Modeling Nodes and Leaves.
A hierarchy can contain 50,000-100,000 leaves at most. If your hierarchy is larger, you should insert a level that is used as a navigation attribute or preferably as a separate characteristic in the dimension table.
9. You can use Level Maintenance and Hierarchy Attributes to set how the hierarchy is to be displayed and processed in reporting (see Level Maintenance and Hierarchy Attributes).
10. Save the hierarchy.
Your assistance will be appreciated.

Hierarchy not used in this case. Could not fnd an answer.

Is dao pattern is the best practice in projects

let me know if dao pattern is the best followed in all almost all the
projects though finding alternatives to it. please clarify this for me and also i do want to know the best practices of the industry in using design patterns.

There is no 'best' pattern. It is just all abouthow
and where to apply them. This is very true,but these are common
design patterns used in industry for standard
problems.
ost of the time patterns are used not for some
special reason but for more manageability and ease of
change.So if you have a small application than it's
ok but if you are working on big application which
are needed to be maintained over a time and changes
are frequent.Than its better to start learning about
patterns because their will be problems which right
now you can't see but eventually you have to take
care of.That is either incorrect or phrased poorly.
Patterns come about because someone analyzes different existing code bases and notes that there are similarities in the way they are built.
It isn't that they are easier to maintain but rather that because the pattern has similarities it is easier to comprehend, understand the limitations, understand the possible related patterns, etc. That might lead to easier maintainance but it isn't the reason. The reason is because, if and only if, the requirements/architecture lead to a situation where that pattern could be properly used.

Use of synchronisation with the SUN DAO Pattern

With reference to the design pattern Core J2EE Patterns Data Access Object: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
I am writing a DAO package to handle access to multiple datasources at a record level (e.g. user records may be located at datasource A, but customer records at datasource B). The role of the package is to provide DAO objects to clients (e.g. business objects in an application package to come later). Nothing too unusual. I have digested the SUN design pattern for DAO.
As I understand it, it can be summarised as: client code calls on an abstract DAOFactory to provide the appropriate concrete DAOFactory . The concrete factory can then supply the correct DAO object. The concrete DAOFactory is also responsible for providing the connection services (such as pooling). So far so good. I have pasted the concrete DAOFactory code form the design pattern page:
// Cloudscape concrete DAO Factory implementation
import java.sql.*;
public class CloudscapeDAOFactory extends DAOFactory {
public static final String DRIVER=
"COM.cloudscape.core.RmiJdbcDriver";
public static final String DBURL=
"jdbc:cloudscape:rmi://localhost:1099/CoreJ2EEDB";
// method to create Cloudscape connections
public static Connection createConnection() {
// Use DRIVER and DBURL to create a connection
// Recommend connection pool implementation/usage
*** can a connection pool be implemented in a static method? ***
public CustomerDAO getCustomerDAO() {
// CloudscapeCustomerDAO implements CustomerDAO
return new CloudscapeCustomerDAO();
public AccountDAO getAccountDAO() {
// CloudscapeAccountDAO implements AccountDAO
return new CloudscapeAccountDAO();
public OrderDAO getOrderDAO() {
// CloudscapeOrderDAO implements OrderDAO
return new CloudscapeOrderDAO();
I have some questions on this overall design.
1) The design for the factories as given looks inelegant and requires upgrading each time a new DAO is added ? much better surely to dynamically generate the DAOs using reflection. If I implement a mapping of data type to data source using a properties file (typical entry, Key = Role, Value = Oracle), the use of abstract and concrete factories can be reduced to a single factory. The single factory reads in the mapping on initialisation and provides a method getDAO to client code. The method takes the data type, looks up the data source and returns the correct DAO class using reflection (e.g. the client passes ?Role? to getDAO and the factory returns Oracle + DAO + Role = OracleDAORole.class). This also has the advantage that the client code does not need to specify the data source to use. I have read some forums and note that performance is an issue with reflection; however I have not seen any significant difference in performance between using reflection to generate a class name and using a factory pattern (e.g. testing just the code paths, for 10 million operations, both reflection and factory took 2.5 seconds each). Does anyone have any opinions on the pros and cons of this approach?
2) If we go with the original DAO design (ignoring 1 above) I have marked the part of the concrete factory code that I have a problem with: using a connection pool in the concrete factory. As the factory?s createConnection method is static, you cannot use NotifyAll or Wait methods here, and therefore you cannot synchronise access to the pool (correct?). I have therefore created a separate connection pool class (which uses the singleton pattern and uses synchronised methods to manage the pool). Is this a sensible way to approach this or is there a clever way to synchronise access to static methods?
Thanks in advance - Alan

These resources may be helpful:
http://daoexamples.sourceforge.net/related.html
http://daoexamples.sourceforge.net/index.html

Implementing DAO Pattern in ABAP

This discussion implement DAO pattern asked the question of how to develop a DAO pattern in ABAP but i'd like to go a little deeper.
The only answer given suggested the following design pattern:
I don't have an coded example here, but isn't it sufficient for this pattern to build an interface with some get- and set-methods? This interface can be implemented by several classes with different data retrieval logic. Then a static factory-method could do the job to decide during runtime which actual class is instantiated, returning the interface.
Can anyone give an abstract description of this implementation relative to an SAP module (How would one approach this implementation in MM, PM, FICO, HR)
Can anyone see any issues in this design?
Can anyone provide an alternate design?
Are we missing any steps?
Together we can build a solid abap DAO everyone can use.

I started to read about DAO pattern some days ago and found this great blog post:
ABAP Unit Tests without database dependency - DAO concept
I am starting to implement unit test in my developments and DAO pattern seems to be a clever choice.
Regards,
Felipe

Tree hierarchy in F4 help

hi all,
I have a requirement like,
in transaction VBG1/2/3. i have to add a 5th tabstrip "MC Hier" and this tab structure is same as the one of 4 structre, But in one field Merchandise Category when we click on F4 for data selection then it should show a tree structure.
The search help should show a tree. The tree should start with one entry u201CRIMOSu201D. If there are children to a branch a + should be shown in the tree. Selecting the hierarchy number should put the hierarchy number in the u201CMC Hieru201D field.
The hierarchy can be read by reading tables:
KLAH
KSSK
SWOR
An example of a tree hierarchy is shown below:
643     RIMOS     RIMOS
     1098     10_SHOP     SHOP_RIMOS
          625     910     FRESH
               626     91010     MILK MILK PRODUCTS EGG SOY
please help me how to do it ...

An example of a tree hierarchy is shown below:
643     RIMOS     RIMOS
                          1098     10_SHOP     SHOP_RIMOS
                                 625     910     FRESH
                                                     626     91010     MILK MILK PRODUCTS EGG SOY

Help on DAO pattern

Hello!
I'm having a problem implementing the DAO pattern.
Suppose that I have two database tables:
emp(id, name, sex, deptid)
dept(id, name)
If I follow the DAO pattern, I use two DAO interfaces, one for each
table, and "entity". EmployeeDAO, and DepartmentDAO.
(I'm using an abstract factory to create storage-specific DAOS)
These DAOs return instances of Employee, and Department, or lists of them. (ValueObjects).
This is all great and works very well, but suppose I want to produce the following
presentation on the web:
deptname | male | female
Dept A   | 10   | 20
Dept B   | 15   | 30In essense, this is a request for all the departments.
I would iterate through this list, and want to display how many
males, and how many females there are in each department.
Should this be in the DepartmentDAO, or in a separate DAO?
Or should this be put in some BusinessDelegate?
That is, DepartmentDelegate.countMales(dept);
Or should I put a method in the ValueObject Department that in turn uses the DAO to count males?
Or should I load the number of females into the valueobject when fetching it from the
database in the first place?
Or should I construct a specialized view of the department such as:
class StupidViewOfDepartment
   private Department dept;
   private int males;
   private int females;
   public StupidViewOfDepartment(Department dept, int males, int females){
   public int numFemales();
      return females;
   public int numMales(){
      return males;
}...having some class return a collection of this specialized view?
In that case, which class would that be?
A new DAO or the DepartmentDAO?
All classical examples of DAO patterns that I can find, fails to adress
other issues than just retreiving a single Employee, or a list of them.
Can someone advise me on this?

You said:
My problem might be, that the data I'm asking for, is not distinct objects, business objects,
but a "new type of object" consisting of this particular information, that is
deptname, numMales, numFemales.
EXACTLY! You are querying for data that is either aggregate, a combination of various other business objects or a very large set of known business objects. In any of these cases, you probably don't want to use a vanilla DAO. Write a dedicated search DAO. Depending on your OO purity level and time horizon, you could make VO's for the search request or the results returned.
You said:
I'd like to think of this as report functionality, or aggregate reports.
I'm good at database programming, and I'm particularly good at optimization,
so if I cannot do this the good-looking way, I can always resort to brutal techniques...ehum
PERFECT! If you are great at database operations, and you know exactly how you want to optimize a given search, then give it its own DAO. The main problem with the object->relational boundary is that most cookie-cutter solutions (ala entity beans with CMP) cannot even remotely appropach the optimization level of a good database programmer. If you want to optimize a search in SQL or a stored procuedure, do that. Then have a dedicated search DAO use that funcitonality. (If you want to do it "right", make a search Factory object that will return various implementations, some may be vendor-specific or optimized, others might be generic; the Factory simply returns a search DAO interface, while specific implementations can concentrate on the task at hand. Swapping implementations with the same interface should be trivial).
- Saish
"My karma ran over your dogma." - Anon

DAO pattern & Lookup datasource with NamingException in the same J2EE APP

Hello Experts:
I'm developing an J2EE application with EJB's for transactional operations (that works fine!) and I'm implementing the J2EE DAO Pattern using a DAO ConnectionFactory with OpenSQL/JDBC standard for Querying the DB, but here my problems begins:
The DAOConnectionFactory Singleton Class is placed in a java package inside the same application that holds my Entitys & Sessions (remember this ejb's works fine!) and I'm trying to get the "localy-configured-in-the-j2ee-application" alias-datasource for my DAO Querys, but "lookup" doesn't find this resource!!!.
I'm thinking, there's not remote access to this resouce because the DAO-CF is in the same context and JVM, but this appreciation is correct? or what I miss?
Another remark: I've been used the Telnet Administrator and the same lookup string is founded correctly!.
Here is the Codec:
public class ConexionFactory implements Serializable {
     private static ConexionFactory singleton = null;
     private DataSource ds;
     protected ConexionFactory() {
          String source = "jdbc/BURO_COMM";
          try {
               Context ctx = new InitialContext();
               ds = (DataSource) ctx.lookup(source);
               if (null == ds) {
                    throw new RuntimeException("Couldn't get the datasource");
          } catch (NameNotFoundException e) {
               throw new RuntimeException(e.getMessage());
          } catch (NamingException e) {
               throw new RuntimeException(e.getMessage());
     public static ConexionFactory getInstance() {
          if (null == singleton) {
               singleton = new ConexionFactory();
          return singleton;
.... (some other methods)

Hello all again:
I've been making some tests (and investigation reading other posts) and I found that everything is related with the Resource Sharing Scope of my Session Object that commands the process. And it works fine.
By now, for my conceptual test is Ok and finally i must work in this app arquitecure path:
->Web Service (with a POJO in a web module)
>ProcessRender Class (a POJO with the main control logic)
>BussinesDelegate's -->ServiceLocator
>SessionFacades --->Entity's
>DAO Connection Factory---->OpenSQL/JDBC Querys

Questions about DAO pattern

Hi,
I am a junior programmer and I am trying to understand somewhat more about best practices and design patterns.
I am looking for more information regarding the DAO pattern, not the easy examples you find everywhere on the internet, but actual implementations of real world examples.
Questions:
1) Does a DAO always map with a single table in the database?
2) Does a DAO contain any validation logic or is all validation logic contained in the Business Object?
3) In a database I have 2 tables: Person and Address. As far as I understand the DAO pattern, I now create a PersonDAO and an AddressDAO who will perform the CRUD operations for the Person and Address objects. PersonDAO only has access to the Person table and AddressDAO only has access to the Address table. This seems correct to me, but what if I must be able to look up all persons who live in the same city? What if I also want to look up persons via their telephone numbers? I could add a findPersonByCity and findPersonByTelephoneNumber method to the PersonDAO, but that would result in the PersonDAO also accessing the Address table in the database (even though there already is an AddressDAO). Is that permitted? And why?
I hope someone can help me out.
Thanks for your time!
Jeroen

That is exactly what I am trying to do. I am writing it all myself to get a better understanding of it.
Please bear with me, because there are some things I dont understand in your previous answer.
1) Each BO validates his corresponding DTO and exposes operations to persist that DTO. Each DTO will be persisted in the database via his corresponding DAO. So this would be:
- in PersonBO
public void save(PersonDTO personDTO) {
this.validate(personDTO); // does not validate the nested address DTOs
this.personDAO.save(personDTO); // does not save the nested address DTOs
- in AddressBO
public void save(AddressDTO addressDTO) {
this.validate(addressDTO);
this.addressDAO.save(addressDTO);
Am I viewing it from the right side now?
2) Imagine a form designed to insert a new person in the database, it contains all fields for the Person DTO and 2 Address DTOs.
How would I do this using my Business Objects?
This is how I see it:
// fill the DTOs
daoManager.beginTransaction();
try {
personBO.setDao(daoManager.getDao(PersonDAO.class));
personBO.save(personDTO); // save 1
addressBO.setDao(daoManager.getDao(AddressDAO.class));
addressBO.save(personDTO.getAddress(1)); // save 2
addressBO.save(personDTO.getAddress(2)); // save 3
daoManager.commit();
catch(Exception e) {
daoManager.rollBack();
If I insert the transaction management inside the DAOs, I can never rollback save 1 when save 2 or save 3 fail.
It can be that I am viewing it all wrong, please correct me if that is the case.
Thanks!
Jeroen

Hibernate, DAO pattern and tree hierarchy

Similar Messages

Maybe you are looking for