Computers have been my hobby since I was 12. Now I'm a freelance Java developer. Like many other developers I am working on various private projects. Some are open source components (Butterfly Components - DI container, web ui, persistence api, mock test api etc.). Some are the tutorials at tutorials.jenkov.com. Yet others are web projects. I hold a bachelor degree in computer science and a master degree in IT focused on P2P networks. Jakob has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

One Big DAO, or One DAO Per Table/Object?

07.30.2009
| 24487 views |
  • submit to reddit

For a long time I have been doing DAO's in my applications.I have usually used the model of having one DAO per type persisted, or per database table. You know, a PersonDao, a CarDao, a BlablaDao etc.

Today, as I was writing an application in which I am too lazy to use a DAO layer (because most
of the persistence operations are 1-liners), I was thinking: Should I add that DAO layer, or should
I not care? Well, of course I should add the DAO layer, so SQL statements etc. can be reused,
and modified in a central place, if the database schema changes. Shame on me for being lazy.

But here is my question to you all:

Do you also use one DAO per type persisted?
Or, do you create one BIG DAO which contains all DAO logic?

I am asking, because I feel tempted to go with just one BIG DAO though I have no experiences
with that. Like I said, I usually use one DAO per type persisted. But a BIIIG DAO seems compelling to me...
Here are the immediate benefits I can see:

  1. It definately makes it easier to find all DAO methods in a project.
  2. It makes it very easy to share connections and transactions between different DAO calls.
  3. You don't get confused about whether readCarsForPerson() belongs in the CarDao or PersonDao
    (I would probably say CarDao since it returns Car's).

By using one big DAO the DAO becomes an abstraction of the total database / datastore, rather than an abstraction of each table / type etc.

What is your opinion on this? One big DAO, or one per type? Does anyone have any experiences?

Published at DZone with permission of its author, Jakob Jenkov.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Simon Martinelli replied on Thu, 2009/07/30 - 2:20am

Hi Adam,

Do you know the CRUD Service described by Adam Bien?

http://www.adam-bien.com/roller/abien/entry/generic_crud_service_aka_dao

I think this could give you a hint.

Kind Regards, Simon

Xavier Dury replied on Thu, 2009/07/30 - 2:33am

see DDD repository pattern: one repository per aggregate root (an aggregate being a cluster of inter-related objects like Order and OrderLine, Order being the root)

Bronek Truszkowski replied on Thu, 2009/07/30 - 3:26am

Hi

I've used a lot of DAO objects, before JPA and when Hibernate was just starting and other object relational mappings were immature it was a great thing.  Even in Delphi i used them ;)

But with automatical O/R mapping for me there's no need to use DAO.  Now, I always create a facade to JPA objects, there's one 'DatabaseConnector' that implements interfaces from JPA (EntityManager's methods) to persis, read, and so on.  If I have 100 persistent objects, creating a DAO for each of them just to implement 'persist', or 'give me a list of all objects' leads to a lot of code that does nothing ;)

 Code must solve a problem, not just follow a pattern 'just because'.
What problems DAO solve, and can we solve it better (or cheaper) with one big DAO ?

1.  predefined SQL statements, methods like 'list of all customers that have names beginning with "bill%"'

with named queries in JPA it would be a shame not to use them.  If something cannot be done in one query, it should be moved to 'logic' lier, it should not be in persistence layer.

2.  Special treatments of some classes during saving/reading and so on. 

Using technologies like Hibernate (or other O/R mappings but I know Hibernate most that's why I refer to it) you can define special treatment without a need for DAO, you define how a class should be saved or read.  Most of 'special treatment' should be done in logic, not in DAO (like business rules checking) so now I need special treatment very seldom - in fact, I didn't use it for about 3 years ;)

 

When I try to think of a problem that many DAO solve, and one big DAO would not solve - nothing comes to my mind - now there are great technologies that in my opinion make many DAO classes obsolete.

Mladen Girazovski replied on Thu, 2009/07/30 - 4:15am

It makes it very easy to share connections and transactions between different DAO calls. 

 IMHO DAOs should be completely unaware of Transactions.

When a Transaction begins/ends is not for a DAO to decide, it's part of the ServiceLaye, at a much higher layer of abstraction.

Otherwise your DAOs won't be as reusable as they should be, every UseCase  of a DAO could have different transaction boundaries.

 For the rest i agree with kalgon, use Repositories & Aggregates, a very nice way to keep your dataaccess & domain model  good structured.

Nicolas Bousquet replied on Thu, 2009/07/30 - 4:53am in response to: Bronek Truszkowski

@bronek

 I just want to add one thing to your comment :

DB access ORM is a technical thing. We map table to object but it's not even real object but just "structures" or what we call pojo with bean notation.

If we think as "services". You call only "services". And it automaticaly perform the business logic, update data and all.

A classic and mature approach is that business rules are in the database as stored procedure. (You can implement them in SQL like or even Java depending on database).

Data update/insert are stored procedures parameters or data pushed in temporary tables. Data read are simple select on a view (to abstract real physical model), or a stored procedure call that fill a temporary table.

This is a very old and mature design. Using temporary table allow you to persist user update between request (on a web server for exemple) without compromising the real database. Using stored procedures allow far better performance (because data read/write/update occurs in DB context without network exchanges and all that costly ORM mapping thing).

With that design you do not have to deal with business logic in JAVA...You juste have DAO to call stored procedures, to read/write in temporary table or views. You are fully transactionnal, the request you do in java are plain simple (no complex query, juste select/insert/update/delete with a where clause restricted to order by and a where condition on an ID).

Modern database like oracle allow you to call stored procedures directly with a web service protocol. If you use an ORM on your application, you juste need the most basic operations because all is done on the database. Transaction always work perfectly at the database lvl, and you can perfectly have a server web dealing with the database, or an heavy client in Swing for exemple (but calling web services if you want !).

You not have to use it for small projects, or if performance doesn't matter. For big information system, you'll gain performance and time... In particular, you code in SQL when you want, in java when you want for business logic... All in stored procedure. In the end, your web server tier, just do what it should have done : server HTML page.

If you use something like GWT, you don't even need to code a simple JSP and do any java code on the web tier. You do code java with is compiled to javascript... And your javascript call directly the web service... At least you need some form of read/write

 

And in particular, you can forget most of J2EE most complex design, performance problem and all.

Jakob Jenkov replied on Thu, 2009/07/30 - 5:48am

Hmm... interesting thought to think in "services" rather than DAO. I mean, a "service" would essentially be very similar to a DAO, but the idea of services could be extended to other aspects of the application, like a "logging service", a "configuration service" etc. However, using that line of thinking, what is really the difference between a service and an API? ...

... except of course that using services my app is being buzz word compliant. Using services internally my application has taken its first step towards being base on a... tadaaa... Service Oriented Architecture... hahaha :-D

VoodooChile replied on Thu, 2009/07/30 - 8:23am

What if, you use different strategies to access your data.

-> One single object: EJBs  (for the rest: use relations).

Eg:  getAbsence(Integer absenceId) will probable just load the persistent object

 

-> An overview with a lot of data : SQL

eg: a dashboard with an overview of people in a unit + all their absences in a given period of a given type, ..

 

Do you make 2 DAO's for that or do you have DAO's that have all technologies aboard?

 

I propose to make a DAO per 'logical business domain' (absences in this case) that delegates to a SQLDaoImpl for SQL stuff and a EJBDaoImpl for EJB retreival.

 

So your DAO decides where it comes from, which data access strategy to use.

It can even implement caching on top of the SQL dao if it wants.

The sub-dao's are technology specific and just do what's asked of them, getting the data we need.

 

Do we need interfaces for the sub-DAO's?  I'd say no because they have no domain meaning, they are implementation helpers sorted by technology. If one day I see the need to move getAbsence to the SQL reader, I'd have to move the interface method as well so why use an interface then.

 The only reason to use an interface would be to have different implementations like an OracleAbsenceDBReader and a MySQLAbsenceDBReader etc or a HibernateAbsenceEJBDAOImpl and a TopLinkAbsenceEJBDAOImpl.

 

So that's a decision depending on your needs...

 

 So yes, I'd say one big DAO per logical domain as mentioned above...

Owen Fellows replied on Thu, 2009/07/30 - 8:34am

I agree with kalgon, I would seperate them logically e.g. Have a seperate Dao for User related objects.  I Use User as an example as often these are objects you want to replace with a User Management component, LDAP or SSO.  So tieing them together with the rest of the application means more work later if any change need to be made.

Peter Karussell replied on Thu, 2009/07/30 - 8:57am

In a project I used one abstract Dao (with generics) with all the necessary methods (getall, findByName, etc).
To avoid that I need to write a lot of code like

new GenericDao<Person>(Person.class).getAll()

I extended this dao for every entity, but that are only 3 lines and could be easily done with code generation tools. Then this is possible:

new PersonDao().getAll()

I think the approach with one fat abstraction-layer is more functional programming, while one dao per entity is more object oriented. Then a method like "readCarsForPerson()" is easier to implement: simply put it into PersonDao as getCars(Person) or in CarDao as getPersons(Car) or whatever.

The coolest thing would be a rails like approach Person.find(:all) ;-)
no need for separate daos, no need for code generation ... but surely not easy possible in Java.

Nicolas Bousquet replied on Thu, 2009/07/30 - 9:26am in response to: Jakob Jenkov

@Jakob Jenkov

In fact, a DSL, an API, a set of services... Are all the same.

 

You define a strict interface on how to interract with your module/software.

You interface can be :

- a SOAP web service : tipicaly slow and usefull only for interroperability and standardisation

- any network protocol (on top of TCP/IP for exemple)

- it can be the memory adress of the program and the order to push param into the stack.

- it can be an object in JAVA that implements a specified interface

- it can be some data you read and write on files.

 

But what technology you choose, what standard you use depend of your needs and/or requirement.

For fast communication, the differents service would be on the same JVM (in java) and a reference to a service will just be an object that implement the good interface. Maybe you'll use spring or Equinox to complexify the whole thing but the concept is the same.

If you are on the web and need communication directly from web browser, web service is a good solution. If you don't have too many message to exchange you can go into the ESB / Web Service thing... It nice to put theses buzz word on your CV. It's likely that in fact it will not help your entreprise at all. Using a slow protocol on top on XML/HTTP will not solve all of your IT problem magically. All of your Information system must be made to use it, and must not have to need more that what this type of technology can offer.

Just to say, in AS400/DB2, you can call RPG programs via SOAP. In Oracle you can call stored procedures using SOAP too.

Using Equinox, you have all the service thing buzz but in the same JVM.

And just use nice defined facade for accessing your API, and you have services.

 

 

 

Rogerio Liesenfeld replied on Thu, 2009/07/30 - 9:52am

For me, assuming that persistence is implemented with an ORM tool (Hibernate, JPA), DAO is an anti-pattern. So is the Repository concept.

Consider a "save" or "persist" method. Does it make any sense to have one such method for each entity class, considering that all such methods will be identical? Even if you use a generified base DAO/Repository class which actually implements that method, there is no advantage in calling it from an entity-specific subclass. The same reasoning applies to a "remove" method. Note that "update" methods don't even need to exist, since the ORM tool will normally execute the necessary SQL "update" statement when the work unit is flushed or commited.

A per-entity "loadById" method is also of dubious value. A more pragmatic solution is to have a single globally accessible method that takes a Class parameter for the desired entity type; through a covariant return type, no cast will be needed.

For "find" methods, I prefer to create them in entity or business service classes. Putting them in an entity-specific Repository class leads to lower cohesion and higher coupling, because (in my experience) most such methods are specific to a single use case.

So, my approach is to use a single persistence facade class that encapsulates the full ORM API.
The benefits:
  1. No unnecessary/duplicate methods for persistence operations.
  2. Greater ease of use, since the facade hides several technical details.
  3. Greater consistency and architectural integrity of the codebase, since there are less ways to solve each given persistence-related problem.
  4. Greater flexibility, since the facade provides a central point to implement workarounds for issues found with different ORM tool versions, JDBC drivers, RDBMSs, etc.
  5. Higher cohesion and lower coupling in business code, mostly because use case-specific finder methods can be implemented where needed as private methods.

I must also point out that the use of a single facade class does not necessarily make unit testing more difficult, even if the persistence facade is a "static class". The use of a static persistence facade is actually my preferred solution, since it allows me to take advantage of static imports, which feels like having an "ubiquitous language" for persistence operations, available anywhere in the application.

Xavier Dury replied on Thu, 2009/07/30 - 9:54am

to elaborate a bit more, you've got to ask yourself how the user of your domain will access data: either by query (on a dao) or by traversal (through another entity). I really think most developpers do not realize there's a choice to be made here, most of them just throw more and more dao's when they need a particular piece of information or chain the getters on entities (which could hurt performance due to lazy loading).

IMHO, I think it is a bad practice to create one dao per entity because you let all doors open to manipulate any data. That way, you cannot enforce invariants. For example, imagine I have a rule saying that an Order cannot have more than 20 OrderLines: if I have an OrderLineDao.persist(OrderLine), nothing will prevent me to put more than 20 lines on an order... and I won't code that rule in my DAO because it's not the right place for the business... so my last choice would be to put this rule in a service and be sure everybody calls this service and not the dao directly (which would bypass my rule). But I will never be sure unless I make the OrderLineDao somehow private and only accessible through the service. But then why have one dao + one service? The right solution here is to access/create the OrderLines through an Order and code my rule into the Order object. Then I'll have an OrderDao to access the Order in the first place, but I won't provide any OrderLineDao (OrderLines will be persisted automatically by your JPA provider).

I think there should be a right balance between traversal and query access depending on your usecases... and I know sometimes it's hard to find out but that's why we get paid for, isn't it? =)

Developer Dude replied on Thu, 2009/07/30 - 10:18am

I use one DAO per type.

One of the reasons is that we have a lot of separate apps/utilities/services that use only some subset of the domain model, often a different subset than the other apps/utils/services. As for sharing connection logic/etc., I let Spring templates handle all that low level logic and just don't worry about it. As already pointed out, typically transactions are not handled at the DAO layer, but rather at the service layer.

It depends on how you use the DAO, and how you foresee using it in the future.

As for skipping it altogether, what happens when you change your persistence implementation? When you go from Hibernate to iBatis? When you go from DBMS to something else altogether (maybe some kind of remote SOAP layer)? Hiding that implementation behind a DAO interface helps decouple services and other users of the DAO from the implementation and then you only have to make the changes in one place. Better yet, with IOC (something like Spring), you can just switch out implementations based on what you need - maybe one app needs to talk to a UserDAO/service backed by MySQL and iBatis, and another needs to talk to a UserDAO/service backed by Active Directory or LDAP - no problemo.

Interfaces are your friend.

Nicolas Bousquet replied on Thu, 2009/07/30 - 11:18am in response to: Developer Dude

@Developer Dude

For me it's not at the DAO lvl that you choose how find the value you need. It's at the service layer.

 The service provide an interface and values objects.

The service layer may choose to load the data from an XML, DataBase, by making a SOAP request, by reading the state of a hardware device and so on. In fact, it may use all of theses methods combined.

Users of your application code shall NEVER NEVER use others methods than the ones provided by the service facade. They shall never manipulate other object you defined than value object ! That why theses object exist, will end with a suffix like "Value"... That why you make an unified facade providing all services for a set of functionnalities.

What going on in the actual implementation code is not the problem of the user of the code, provided that it work as intended.

In most case, you'll not have several service implementation. Maybe one hypothetical day, you'll publish it as web service and make a proxy. You gain network and processing bottleneck, additionnal possible bug and configuration, but you can add the buzz word on your CV ;)

But you'll not have 10 implementation of the same DAO to read the data with 3 differents ORM, by parsing the XML file, using corba... You'll use one implementation, and that all.

It also depend what are DAO object for you. because in the end, DAO objects are technical thing to deal with the database layer.

If the database comes with services as stored procedure, the DAO is just a proxy to the service layer. If the logic is in JAVA, DAO will just load/save data from the database. But the keyword here is the database : DAO layer is a pure technical layer to access the database.

Developer Dude replied on Thu, 2009/07/30 - 2:18pm

foudres,

Thanks for the reply, but never say never.

Everybody's use case is different. Although I don't *think* I was advocating exposing the DAO layer above a service layer, so I don't necessarily disagree there - sorry if I gave that impression. I was simply thinking of the DAO layer with a passing reference to the service layer (which in my view handles a lot more than just persistence - so I think we agree).

For example, with reference to the different implementations of the persistence layer, at a past employer, we needed to support the same persistence logic on three different DBMSs - DB2 for the IBM shops, SQL-Server for the MS shops, and Oracle for the Oracle shops. Above the DAO layer, the biz/service logic on the server side saw the same DAO interface for all datastores. So yeah, we had at least three different implementations. This also makes it a lot easier when you decide to switch from something like Hibernate to iBatis (which is what they did for various reasons).

Then there is indeed the different strategies for a datastore, e.g., XML v. DBMS v. something else. IMO, that should be opaque above the DAO layer (or more opaque), and yes, I have seen that change too. I currently have two different datastores for user management for authentication/authorization, one has users in a DBMS (PostGreSQL) and another uses Active Dir (or could easily use LDAP) - I can and do switch between them depending on the use case, but that happens behind the DAO and the service. Spring Security is a great example of this: the datastore may be in memory, it might be in a Java properties file, it might be in an XML file, it might be in a DBMS, it might be in AD or LDAP - it doesn't matter where it is because it is behind a provider facade (which might or might not have a DAO layer) and you can switch out the provider very easily with just a config file change to the bean definition.

Then there is the case where a DAO/service is a facade for a remote protocol. For example, at a recent employer we had a desktop Swing app that used a DAO layer (with commands on top - which provided a type of service) to talk to a server via SOAP. This might have easily changed to RMI or some other protocol via a different implementation as we saw fit.

My point is, that if DAOs are interfaces and discrete modules, then they can be used (and reused) flexibly as necessary for different services and use cases. The level of granularity is up to the judgement of the developer and may change for the specific use case, but generally I like to build a CRUD DAO for each domain object type, and then each service may (and quite often will) use multiple DAOs for the different use cases. I don't like to put them altogether in one DAO unless there is a compelling reason to do so.

In the domain I am currently working in, there are at least 3 significantly different types of users and at least as many different but related types of businesses for the various domain objects/models we use. They have different workflows, different views on the same and different data (with some overlap), so different services will be created. Where there is commonality of course we will use common services, but conversely we will not try to fit square pegs into round holes.

Rael G.C. replied on Thu, 2009/07/30 - 9:07pm

For small and simple CRUD projects, I even named the EntityManager instance as "dao" (of course, there are no DAO classes): EntityManager dao = Persistence.createEntityManagerFactory("yadayada").createEntityManager();

Dapeng Liu replied on Fri, 2009/07/31 - 12:21am

prefer aggregated DAO design, less configuration codes (which carries the least value per line of code) 

Nicolas Bousquet replied on Fri, 2009/07/31 - 4:57am

@Developer Dude

Okay, you are right, i shouln't have say NEVER ;) I think that your case is particular and i guess mine too.

My case :

For current projet, we have an AS400/DB2 database. Business layer is on the database. We call RPG programs via SQL. We use program parameters or temporary table to send data to the business layer.

Business layer send back the response using temporary tables. At first, it may appear slow but it is indeed very fast. Because the only thing that transit between the database and web server is currenlty displayed data.

But recently we had to support also an AS400 simulator (PKS) for thoses guy that don't want to buy an AS400.In the beginning, all DAO code, hibernate mapping, BO & values object where hand crafted.With even different DAO code depending of the database (Oracle + simulator or AS400 DB2).

When i went into the project i realised that we so much code to do allways the same thing.

Each time we add to implement the same bean for GUI, values objects, BO, hibernate mapping, program call, dao select/insert/delete/update.

So the difference today is that the code is generated. I didn't choose hibernate tool or an MDA system because i had to generate a very specific code to deal with our special case. I had to generated the code by myself.

So each time we have a new program to call... Or a new table to read/write... We make an XML descriptor. Using this descriptor we generate the hibernate mapping for both oracle and DB2. We generate the BO, Value object bean... And the DAO (DAO are the same for both back end, the only difference is on the hibernate mapping and how to call the program).

At least, now it's fast to add new things and you don't spend time rewriting the same code over and over.

But hey, generation is nice... But while coding the code generation, i realised that most code that was possible to generate could be generic too.

In fact i need a specific service layer, with an interface and a list of method to call business programs and to read the result. But there is only a few differents cases and in fact i just call parametrised generic code.

It's not yet the case anywhere but in the end, i have a generated service layer (because the service layer is really defined in the database 99% of the time). And it's just an interface to the database, real or simulated AS400.

To make my generation system full usable, it is extensible. You can define a servide with 90% of methods generated on an Abstract class + base interface and add your own specific code on concrete class and extended interface.

So each case is different I guess.

Jakob Jenkov replied on Fri, 2009/07/31 - 7:24am

Lots of good thoughts here!

 

By the way, I just realized that using one big DAO (or service) is a bit like using a DaoManager, which I wrote about once in the past...

 

http://tutorials.jenkov.com/java-persistence/dao-manager.html

 

Also, I agree that transaction demarcation belongs outside the DAO's. I also wrote a bit about that...

 

http://tutorials.jenkov.com/java-persistence/advanced-connection-and-transaction-demarcation-and-propagation.html

 

Sometimes I just forget what I have already written about, or "realized" earlier :-)

But many good ideas here too, I think. I'll experiment a bit with what I've learned, and see what happens. It's a small project so I can easily switch to a different design, if an experiment "fails".

Developer Dude replied on Fri, 2009/07/31 - 4:54pm

Yes, every problem/environment is similar and yet different at the same time.

I try to be flexible about the tools and solutions I use/arrive at, and adopt them for their suitability of fit - and I try to keep that in mind when looking at someone else's solutions. Sometimes some general rule (e.g., program to interfaces) or tool (e.g., Hibernate v. iBatis) that applies well elsewhere just doesn't make sense in a different situation. It is not always about the domain, but also the environment - even though ideally the latter should have little to no impact, it usually has a moderate to large impact. Having to deal with legacy code, legacy systems, legacy schemas, that are not (or never were) ideal or just plain crufty, and yet cannot be just swept away overnight, can impact your solution in a big way.

So I usually preface my statements with 'it depends'. But I prefer discrete smallish (but cohesive) reusable modules of logic, and that includes DAOs. Since I have a preference for IOC and using Spring, I can both hide a lot of the underlying template/boilerplate logic and have a framework for pluggable/configurable modules. I've only been working with IOC/Spring for less than a year, but I can already see the benefits and potential. I highly recommend going that route. I try to keep in mind that underlying mechanism can change, and I try to keep these systems as decoupled as I can - i.e., persistence decoupled from biz logic, and so on - because if there is one constant it is that things change.

So, if you want to put everything in one DAO, I would ask:

Will it be reusable?

Will it be cohesive?

Will it be decoupled and easily replaceable/refactorable?

As for transactions and connections. I would hope that using transaction management and connection pooling/management, your system would not be worrying about that in the business logic - at least not the connections. I personally never see the connections. I let the Spring templates handle that for me. I configure it in the context and the persistence logic I write has no need to know about the connections.

Nicolas Bousquet replied on Mon, 2009/08/03 - 3:55am

"So, if you want to put everything in one DAO, I would ask:

Will it be reusable?

Will it be cohesive?

Will it be decoupled and easily replaceable/refactorable?"

In my case there is two lvl :

lvl 1) Generic code in utilities classes.

lvl 2) very small DAO classe (one for each operation : call program, read, update, insert, delete - most of the time i have just call program and read). Thes DAO classes simply use the generic code.

Theses DAO are called by the generated service code. Il work nicely for two reasons :

- real service layer is on the database. So all of that DAO/service thing is just intended to provide an easy access to the service interface defined in the database.

- it is possible to add anywhere your own code and mix generated and hand writed code (generated code seat in abstract classes, hand crafted code in concrete implementation).

Because code is generated :

- To add 5 ou 6 programs call, and 5-6 DAO, i just need 3 or 4 hours, writting the XML, generating the code and test that all is fine. Before for the same thing it would need more about 3 days of work.

- To handle specific case... I can code it dirrectly by hand or add a new generation case in my generation system. It depend in fact of  how ofen this case will occur in the future.

In a sence, if i switch to another ORM (i don't see it to happen...), then i just change my generation code and call it again.If i have to get data using another protocol... I can change the generation code too. I will need a few days to change or add new templates of the generation tool, call it one time and voila. i support the new back end/implementation.

 

Walter Bogaardt replied on Wed, 2009/08/05 - 5:19pm

It depends. When I look at it in using a DAO to access a hibernate object, if that object pulls in a collection then I don't do it for the collection. Example: Order object pulls in a collection of OrderDetails objects. I don't then create an OrderDAO and an OrderDetailDAO, because I can just crud through the OrderDAO. 

Walter Bogaardt replied on Wed, 2009/08/05 - 5:23pm in response to: Jakob Jenkov

Yea transaction demarcation I'd do definetly outside of a DAO. Using a Manager or Serivce.

 In terms of big DAO. One method is have a GenericDAO manager that you can use interfaces to and spring to use the generic DAO manger for all basic crud. When you need custom DAO then you work from the GenericDAO Manager to extend your CRUD calls for special queries or persistence needs.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.