This content has been marked as final. Show 9 replies
To me it seems like an over kill.It appears to be an overkill but it will scale better to changes. Then, there is always a balance between the amount of separation you want to introduce with the development time available. Having a DTO and DAO, IMO, hardly takes any development time even for a small project.
If you are certain that you always get one value out of the database, the DTO may be discarded for simplicity.
That's just me and my funny ideas. :)
yes?Ummm. Well glad to see you have returned.
well Martin Fowlwer does propose IdentityMap pattern in such a case where he says that thes objects should be stored in a Map with the primary key being the key for the map. So next time you need an object you check with the map if it exists or not and if it doesnot you try to grab it again.
But IMHO if the hit ratio(no. of times the same data is used again) is less these Maps might pose a nightmare in terms of memory and garbage collection.
So should one use IdentityMap or avoid it?
What do you think.
I can't address garbage collection, but it seems to me if you use
Weak/SoftReferences in your cache the memory issue should be
Why reinvent Hibernate?
I understand the concept of separation of concernseffort = manually typing it?
but I am concerned over here about the amount of
effort required to create these DAOs and DTOs
specially in cases where only one or two fields are
If yes then use code generation. Or a framework.
If instead you are concerned about volume (network, cpu, whatever) then the first step is to actually estimate volume so you can know which parts need extra effort.