• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

DTOFactory using DAO Factory

Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a copy of the patter I sumbitted on TheServerSide.com. This is a really nice store house for enterprise design patterns.

This pattern is a combination of three established patterns.
1. Data transfer object factory
2. Command pattern
3. Data access objects (using abstract factory)
The Data transfer object factory (Implemented as a Session EJB) is the interface to the business client. The only alteration being that the Data transfer object factory does not create any data transfer object as such. The Data transfer object factory in turn uses a command pattern to invoke the specific command that will handle the DTO creation.
The DTO Specific command will have all the entity relationship info needed to create the DTO. It will then invoke the Data access objects abstract factory to get the appropriate factory and then it will call that factory to get the DAO from which it gets the entity values.
The Data access objects (using abstract factory) strategy will ensure that your data source can be anything. It could also be a good way to abstract the business logic from persistence technologies like ORM, EJB (Entity) or Data Objects.
Further clarifications:
DTO Factory is required to be a stateless session bean only if the clients are non-EJB.
You are right it does use the container features of the app server for non-EJB clients.
The DTO Factory is different from the session fa�ade since the fa�ade is just a fa�ade to your persistence framework (entity EJB) and it typically includes business logic. Whereas the DTO Factory in my case is just a routing controller, which uses command pattern to route to, the appropriate command which will handle the DTO creation. (You got this right too)
The Business logic to create the DTO is typically embedded in the command. So the DTO Factory is not cluttered and the commands are free to inherit from a command specific base class other than the DTO Factory.
Ideally speaking the DTO Factory should be called a command controller rather than a factory. But the client side interface to the business clients will be very similar to a DTO Factory. I used the DTO factory term because of this similarity in objectives and thus make it easier for people who are already familiar to DTO Factory pattern.
This is my favorite tiny ad:
a bit of art, as a gift, that will fit in a stocking
    Bookmark Topic Watch Topic
  • New Topic