I am considering writing a Data Transfter Objects factory to go with a Data Access Objects factory for creating Data Transfter Objects which are essentially java representations of a table from an oracle database (there are a lot of tables!). The implementation of the Data Transfter Objects will then be hidden from the Data Access Objects.
//get instance of dao factory //call a method of the dao, e.g. build() //build() gets and instance of dto factory //build() creates the necessary dto's for the dao
after some more thinking, i was wondering whether i could utilize a builder design pattern with the factory/dao pattern so that the factory creates the type of object i want (which can best be described as a composite object, made up of a data pertaining to multiple tables (and multiple rows), over multiple schemas. then the DAO.build() uses the builder to actually construct the object.
Is this roughly what you're thinking? Client is maybe a servlet. Service is something useful in your "model" side.
The Builder idea is fine. One nice thing about factories is that they hide the mechanics of making something, so they can use Builders as necessary. The getDTO("thing") method on line 6 could use a Builder if creating the DTO is complicated.
This does bother me a little bit. If we're creating a new ThingDTO from scratch, we probably don't need to involve the DAO. The DTO factory is still fine, but we could call it right from the service. If we're retrieving an existing Thing into a DTO, say from a database, we might expect a database thingy instead of a DTOFactory.
If you called the DAO a Repository, like Peer's discussion in another thread here, maybe those concerns go away. It could be appropriate for a Repo to handle both create and database things.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi