Re: DAO with EOF
Lenny Marks <[email protected]>
| Newsgroups | gmane.comp.web.webobjects.devel |
|---|---|
| Message-ID | <[email protected]> |
I believe one major benefit of the DAO/POJO pattern has do with testability, particularly when combined with dependency injection/ Inversion of control(ex. Spring) as many have come to do. It's a lot easier to test code that uses a DAO for fetching over the static factory alternatives like Employee.findByX. The same goes for direct EOFetchSpecification usage. You can stub/mock DAO interfaces (Easymock) so that you can test the things that use them in isolation without preloading a database with test data or even connecting to one. You may find these old threads relevant. http://www.omnigroup.com/mailman/archive/webobjects-talk/2006- September/000495.html http://www.omnigroup.com/mailman/archive/webobjects-talk/2006- September/000496.html *http://www.omnigroup.com/mailman/archive/webobjects-talk/2006- September/000500.html -lenny On Nov 14, 2007, at 1:22 PM, Anders Peterson wrote: > Daryl Thachuk wrote: > >> On 13-Nov-07, at 5:11 AM, Anders Peterson wrote: >>> Hi, >>> >>> I'd like to make my business objects independent of EOF. Thinking >>> about doing doing this using the Data Access Object design >>> pattern where the EOs are the DAOs and the BOs are POJOs. >>> >>> http://java.sun.com/blueprints/corej2eepatterns/Patterns/ >>> DataAccessObject.html >>> >>> Is (something like) this commonly done? Has anyone done it? >>> >>> /Anders >>> >> Why would you want to do this? > > I've started thinking about this because I have two different > application in the same domain - one is a WebObjects app the other > one is not. Trying to figure a pattern that will allow me to share > as much code as possible between the two apps. > > /Anders > >> I think this pattern exists because of limitations in J2EE. >> Limitations which do not exist in EOF. >> Of course I could be wrong :-) >> -daryl >> ------ >> Daryl Thachuk >> Montage Technologies Inc. >> http://www.montagetech.com >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> WebObjects-dev mailing list >> [email protected] >> http://www.omnigroup.com/mailman/listinfo/webobjects-dev > > _______________________________________________ > WebObjects-dev mailing list > [email protected] > http://www.omnigroup.com/mailman/listinfo/webobjects-dev >