J2EE patterns: DTOFactory using DAO Factory
This pattern is a combination of two established patterns.
- Posted by: Sunil Nair
- Posted on: November 19 2002 17:39 EST
1. Data transfer object factory
3. Command pattern
2. 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.
- DTOFactory using DAO Factory by Sunil Nair on November 19 2002 17:46 EST
- DTOFactory using DAO Factory by Devendra Kabre on November 20 2002 06:38 EST
- DTOFactory using DAO Factory by Gal Binyamini on November 22 2002 16:44 EST
- DTOFactory using DAO Factory by Nate Borg on November 24 2002 14:34 EST
- DTOFactory using DAO Factory by Sunil Nair on November 25 2002 16:22 EST
it should be three patterns instead of two but then command pattern is embedded in the DTO Factory pattern.
Good to see your DTOF pattern ...
Correct me if I am wrong the way I understand it ..
you are using command pattern to invoke the specific command that will handle the DTO creation.
Data access objects (using abstract factory)
to abstract the Data Source
DTOF Session Bean sounds pretty similar to a Session Facade with a combination of DAO and Comand Pattern..
a good thought of Abstracting things out.
Also hoping the DTOFSessionBean takes care of the Transaction Support provided by the app Container ???
Would also love to see the EJBProxy invoking the DTOFSessionBean.
Good to know that you liked it. Though I am sure to get a lot of criticism also. This will help me in further refining this pattern.
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.
I don't think this is a design pattern. DTO is a pattern. In it's implementation, you can make use of a Command pattern. I'm not saying it's not a good idea, just that this doesn't make a design pattern. If we started listing every possible combination of design patterns we would end up with a giant incomprehensible list of very specific combinations. The concept behind design patterns is that we can learn a few ideas that are very useful, not many ideas each being useful for one specific situation (even if in that situation it's indeed a very good idea).
I do think this kind of thing can be listed as a "design pattern relation". Unfortunately TSS doesn't currently support this kind of thing (it doesn't even support changing the pattern description, so it impossible to even add it to the description). Maybe you can post it on the bottom of the DTO pattern thread, though I doubt many people will ever get this far down the thread to see it.
I sent you an email last week requesting that you send me a more detailed description of your original pattern posting. In case you didn't receive that email, I thought I might post the same request here.
We are currently in the process of adding a feature where you can go in and update your original postings, but for now, please email me nitin at theserverside dot com, if you'd like any of your postings to be updated.
You are very true in the sense that this is not a design pattern and I do not claim it to be although a lot of so called new design patterns are just interesting combinations of existing design patterns. There is nothing wrong about it in my view.
In fact most of the listing on the server side are J2EE specific implementation of well-established GOF patterns.
There is a lot behind implementing a pattern depending on your scenario and the strengths and weaknesses of your implementation framework (like entity beans are just good for a specific set of tasks) it will certainly help if we can share what we find with the rest of the community.
I does not make a whole lot of sense to have a set of abstract patterns (already well documented in GOF books) like in some basic university text book and not have any concrete use of how it is implemented in J2EE. You know how boring textbooks are. A lot of people will not like that.
If your concern is about cluttering up the main page a point well taken but then like you said I hate to add it to the DTO Factory mailing list where it will lie buried. And besides it is not just DTO Factory it could also be in command pattern or DAO pattern or abstract factory or …so on and so forth.
Like I said I prefer usability and usefulness to neatness and keeping thinks in order. I do not want the server-side to be a law book.
And I will not really mind if the server side pattern page is full of J2EE implementation of design patterns, which make sense, and we can discuss constructively about how it will be better implemented. In fact a whole lot of people working on real projects will like it too.
I am not arguing against the usefullness of documenting specific design pattern implementations or specific design pattern combinations. All I'm saying is, they are not design patterns. In a perfect TSS, I would like to be able to go to the DTO Factory design pattern, click a "related patterns" or "implementation discussions" link and see some usefull combinations of patterns or good implementations. I think that would be much prefferable, not only in terms of order, but also in practice. When a developer comes in to TSS and looks at a design pattern he would be able to see all the related discussions/implementations directly rather than have to look for them in the patterns section (which is misleading, since they aren't patterns) or in the discussions section (where they will be burried).
I completely agree that most of the design patterns listed in TSS are design pattern implementations at best. Some of them are not even design pattern implementations, they are just specific-purpose algorithms (see key generations "patterns" for instance).
I hope the TSS guys are going to put some effort on upgrading the patterns section, despite the technical difficulties involved. See this related discussion.
Gal, I continue to queue your excellent feedback. We will approach you when the time comes to revamp this section and bounce some design documents off you. Hang in there, we're on it, we're just working on some more immediate concerns at the moment.
I was off on vacation for a while.
Gal I read (a part) of your link and it does make sense.
There should be a pattern documentation template.
and there should be a template for tss. This will make it much easier for readers.
I guess I do not visit server side so often, because I did not know of this ongoing task.
There will be none happier than me to see this wealth of information better organized.