Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

DTOFactory using DAO Factory  RSS feed

sunil g nair
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is a copy of the patter I sumbitted on 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.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!