DAO Pattern Confusion
Hello,
Have started developing with J2EE recently, moving up from J2SE. With regards to persistance of data to a database I have been looking at the DAO pattern. I am a little confused about this pattern, so I hope someone may be able to clear a few things up.
As I understand it the Transfer Object (TO) can be a simple java bean with getter and setter methods.
The DAO can only have four methods, create, read, update and delete. I am a little confused here, because as I see it, we can only have these four methods to read/write from/to the TO.
Isn't this very limiting? For example, the update statement of the DAO will have to have a TO which has already been populated, for this to occur an already populated TO has to be generated (a read on the DAO) and then the required values changed via the get/set methods of the TO. Then a method of the DAO has to be called to persist this data to the database.
This would cause difficulties if we wanted to implement optimistic locking for example, where we wanted to check if a row had been changed before commiting the change (to prevent lost updates).
Would it not be better to have many methods in the DAO, and a customer TO for each one? E.g. methods such as:
TO to = new TO();
to.setState("new");
to.setWhere("old");
dao.updateState(TO to)
Such a design would let us update the state of a row in the database to "new" where the state previously was "old" and hence be a basic implementation of optimistic locking.
Or are we completely missing the point!
Many thanks,
[1608 byte] By [
RaviSingha] at [2007-10-2 8:45:44]
I think the TO should be concerned with its state. You might have many TOs, each in a different state. they should be the ones keeping track of their state, not the DAO.
I hope one of those states is "unpersisted" or "new, not saved yet".
Going to track each attribute as "dirty" or not?
I don't think a DAO needs more methods than those. You can have multiple reads that will correspond to different WHERE clauses, but that's all a DAO should do.
I think asking a DAO to keep track of the state of each TO is wrong. Let the TOs maintain their own state.
Personally, I think TOs are an anti-pattern, not a best practice. They came about because entity beans have been a failure.
I'm moving away from EJBs and towards POJO persistence using Hibernate. I think it's a much better solution.
%
Happy new year Duffy! :^)- Saish
Saisha at 2007-7-16 22:48:13 >
and the same to you, Saish! doing anything good tonight?
i went to see "chronicles of narnia" this afternoon and then went out to dinner. it started snowing late this afternoon, so by the time we finished dinner it was treacherous driving conditions. i'm home now with my doggie at my feet, glad to be off the road.
%
Only to add to Duffy's (as usual) salient and succinct points:
> Hello,
>
> Have started developing with J2EE recently, moving up
> from J2SE. With regards to persistance of data to a
> database I have been looking at the DAO pattern. I am
> a little confused about this pattern, so I hope
> someone may be able to clear a few things up.
>
Data access objects bridge the 'object-relational' boundary. Your object model has different concerns than your relational persistence model. For 80% (maybe more) of your system, the two will nearly match. However, for the rest, you need to manage the differences between your relational and object models. As Duffy alluded to, O/R mappers, such as Hibernate or JDO, are excellent candidates for new systems within the 80% of the convergence between relational and object models.
> As I understand it the Transfer Object (TO) can be a
> simple java bean with getter and setter methods.
>
IMO, this model is broken. TO's, as traditionally implemented, are read-write. In most cases, it is easier to code a TO as read-only. Provide instance values in the constructor and then expose only getter methods. One possible implementation is to have the DAO and the TO (or preferably model object) in the same package. Make the constructor of the TO protected (or package private). Then, the DAO can initialize values from the persistent store, but users of the TO will only be able to read the values retrieved. If this model becomes limiting, you should realize that you are now allowing mutator methods. IMO, your TO should now be a fully-fledged domain model object.
> The DAO can only have four methods, create, read,
> update and delete. I am a little confused here,
> because as I see it, we can only have these four
> methods to read/write from/to the TO.
>
This is roughly what a database allows. However, what of commonly used parent-child or foreign-key relationships? You may retrieve an account holder and his/her present balance 90% of the time in your system. Do you want two separate TO's and DAO's here? Or is this a case where a DAO can construct a graph of objects in memory as an optimization?
> Isn't this very limiting? For example, the update
> statement of the DAO will have to have a TO which has
> already been populated, for this to occur an already
> populated TO has to be generated (a read on the DAO)
> and then the required values changed via the get/set
> methods of the TO. Then a method of the DAO has to be
> called to persist this data to the database.
>
The more your object and relational models converge, the more this will be true. In my experience, there usually remains 20% of your object model that does not really map well to your relational model. Usually, these objects are also the sources of complexity in your system. So, here, your DAO's will be 'richer' and less 'simple' than the scenario you outline. However, for a good percentage of objects, your assertion does hold true.
> This would cause difficulties if we wanted to
> implement optimistic locking for example, where we
> wanted to check if a row had been changed before
> commiting the change (to prevent lost updates).
>
I would not implement this myself. As Duffy has alluded to, Hibernate and other O/R mapping technologies maintain the state of an object and the state when it was retrieved, allowing the framework to update only modified fields when needed.
> Would it not be better to have many methods in the
> DAO, and a customer TO for each one? E.g. methods
> such as:
>
> TO to = new TO();
> to.setState("new");
> to.setWhere("old");
>
> dao.updateState(TO to)
>
> Such a design would let us update the state of a row
> in the database to "new" where the state previously
> was "old" and hence be a basic implementation of
> optimistic locking.
>
Again, only for objects that map to a single table row.
> Or are we completely missing the point!
>
> Many thanks,
It's a complicated subject. Don't lose heart. :^)
- Saish
Saisha at 2007-7-16 22:48:13 >
Had to work earlier (@#@$!). Nothing too big. Got my lady coming over in a bit. So, bringing in this new year better than last. :^)
I liked Chronicles of Narnia. Read it last at least 20 years ago. But as soon as the story started, it all came back. Always hated Edmund. Though it was interesting seeing it as an adult, understanding more of the religious allusions than when I was younger. My favorite in the series was "Voyage of the Dawn Treader". If they make that one, count me in!
- Saish
Saisha at 2007-7-16 22:48:13 >
> Had to work earlier (@#@$!). Nothing too big. Got
> my lady coming over in a bit. So, bringing in this
> new year better than last. :^)
Excellent!
> I liked Chronicles of Narnia. Read it last at least
> 20 years ago. But as soon as the story started, it
> all came back. Always hated Edmund. Though it was
> interesting seeing it as an adult, understanding more
> of the religious allusions than when I was younger.
> My favorite in the series was "Voyage of the Dawn
> n Treader". If they make that one, count me in!
>
> - Saish
I read them to my youngest daughter in 1999 and liked them very much. I read and re-read Tolkien starting when I was fifteen. I think they're stronger stories than Narnia, but I still liked both.
I think the religious symbolism is strongest in the first book and tails off from there. CS Lewis wrote a lot about his Christianity (e.g., "The Screwtape Letters"), but I think the Narnia books stand on their own even if you don't buy into the allegory.
Have a great evening! I'm going to be online for a while.
%
duffymo said
> Personally, I think TOs are an anti-pattern, not a
> best practice. They came about because entity beans
> have been a failure.
>
> I'm moving away from EJBs and towards POJO
> persistence using Hibernate. I think it's a much
> better solution.
And to emphasize that this is duffymo's personal opinion.
One that others do not share.
And in particular I would like to point out that I was using DTO's before J2EE, much less entity beans existed. Not only in a POJO framework but in C++ as well. So for me they certainly didn't come about due to a failure in EJBs.
> Hello,
>
> Have started developing with J2EE recently, moving up
> from J2SE. With regards to persistance of data to a
> database I have been looking at the DAO pattern. I am
> a little confused about this pattern, so I hope
> someone may be able to clear a few things up.
>
> As I understand it the Transfer Object (TO) can be a
> simple java bean with getter and setter methods.
First it is not a requirement that setter/getters be used. The members can simply be public.
Second, I generally relate the functionality to a DTO to be 'trivial'. Thus I can and do add validation methods (for example) which do nothing but simple validation of the attributes. It is important to emphasize the simple part. I might validate that a require value exists. I don't validate that a unique value is unique for other DTO instances. Basically the validation must be done only with the data that is in the DTO itself.
I do this not necessarily because it is an ideal solution but rather because it is the best solution given the context it which I am developing the application.
Emphasizing again that the functionality must be simple though.
>
> The DAO can only have four methods, create, read,
> update and delete. I am a little confused here,
> because as I see it, we can only have these four
> methods to read/write from/to the TO.
>
It should only have methods that perform that but that doesn't mean there can only be four of them. Particularily for queries I often have several.
> Isn't this very limiting? For example, the update
> statement of the DAO will have to have a TO which has
> already been populated, for this to occur an already
> populated TO has to be generated (a read on the DAO)
> and then the required values changed via the get/set
> methods of the TO. Then a method of the DAO has to be
> called to persist this data to the database.
>
Huh?
If you don't start with something how do you know what to update?
> This would cause difficulties if we wanted to
> implement optimistic locking for example, where we
> wanted to check if a row had been changed before
> commiting the change (to prevent lost updates).
>
I would suggest that you consider very carefully if you want to do this. In my experience 'overwriting updates' has always been initiated by either developement or QA and with further research it has been determined that there is no valid business reason for it. It is something that normal business flow just can't generate.
After all, how often do you expect a customer to update their billing address, when two people are requesting it at the same time and they are requesting different addresses?
> Would it not be better to have many methods in the
> DAO, and a customer TO for each one? E.g. methods
> such as:
>
> TO to = new TO();
> to.setState("new");
> to.setWhere("old");
>
> dao.updateState(TO to)
>
> Such a design would let us update the state of a row
> in the database to "new" where the state previously
> was "old" and hence be a basic implementation of
> optimistic locking.
>
> Or are we completely missing the point!
There are a variety of ways to do this. For example have a DTO that has the old and new values. On an update validate the old values are the same before doing the update. Or use a last update timestamp (which has the advantage of allowing tracking as well.) Or as you suggested keep a dirty flag in the DTO (although I personally would not be in favor of that sort of design.)
>
> IMO, this model is broken. TO's, as traditionally
> implemented, are read-write. In most cases, it is
> easier to code a TO as read-only. Provide instance
> values in the constructor and then expose only getter
> methods. One possible implementation is to have the
> DAO and the TO (or preferably model object) in the
> same package. Make the constructor of the TO
> protected (or package private). Then, the DAO can
> initialize values from the persistent store, but
> users of the TO will only be able to read the values
> retrieved. If this model becomes limiting, you
> should realize that you are now allowing mutator
> methods. IMO, your TO should now be a fully-fledged
> domain model object.
>
I disagree. And apparently others do as well because your model is the way that J2EE first represented DTOs (as a "Value Object").
I suppose my reason for this would be that most of the work in other layers involves sending mutated data back. With your pattern this requires that the user, every single time, create a new object, copy the old data to the new, and then send the new object back.
Extra work with no gain.
> > The DAO can only have four methods, create, read,
> > update and delete. I am a little confused here,
> > because as I see it, we can only have these four
> > methods to read/write from/to the TO.
> >
>
> This is roughly what a database allows. However,
> what of commonly used parent-child or foreign-key
> relationships? You may retrieve an account holder
> and his/her present balance 90% of the time in your
> system. Do you want two separate TO's and DAO's
> here? Or is this a case where a DAO can construct a
> graph of objects in memory as an optimization?
>
There are several other J2EE patterns for complex relationships.
I am not sure I have ever encountered a need for those though.
>
> > This would cause difficulties if we wanted to
> > implement optimistic locking for example, where we
> > wanted to check if a row had been changed before
> > commiting the change (to prevent lost updates).
> >
>
> I would not implement this myself. As Duffy has
> alluded to, Hibernate and other O/R mapping
> technologies maintain the state of an object and the
> state when it was retrieved, allowing the framework
> to update only modified fields when needed.
>
Interesting.
> duffymo said
>
> > Personally, I think TOs are an anti-pattern, not a
> > best practice. They came about because entity
> beans
> > have been a failure.
> >
> > I'm moving away from EJBs and towards POJO
> > persistence using Hibernate. I think it's a much
> > better solution.
>
> And to emphasize that this is duffymo's personal
> opinion.
>
> One that others do not share.
Joe's correct on both counts.
I would like to hear Joe's response to the question about whether or not it's considered a good design to have two parallel class hierarchies, one for business objects with rich behavior and another of DTOs that mirror the attributes of the business objects without the behavior, solely for the purpose of ferrying data between layers. I've never understood the need for DTOs when the business objects themselves are perfectly capable of transporting their state.
> And in particular I would like to point out that I
> was using DTO's before J2EE, much less entity beans
> existed. Not only in a POJO framework but in C++ as
> well. So for me they certainly didn't come about due
> to a failure in EJBs.
OK, I'll buy that, but I'd still like to hear your response to the question above.
I'd also like to hear why you thought they were necessary in a non-EJB context. Thanks, Joe.
%
> >
> > IMO, this model is broken. TO's, as traditionally
> > implemented, are read-write. In most cases, it is
> > easier to code a TO as read-only. Provide
> instance
> > values in the constructor and then expose only
> getter
> > methods. One possible implementation is to have
> the
> > DAO and the TO (or preferably model object) in the
> > same package. Make the constructor of the TO
> > protected (or package private). Then, the DAO can
> > initialize values from the persistent store, but
> > users of the TO will only be able to read the
> values
> > retrieved. If this model becomes limiting, you
> > should realize that you are now allowing mutator
> > methods. IMO, your TO should now be a
> fully-fledged
> > domain model object.
> >
>
> I disagree. And apparently others do as well because
> your model is the way that J2EE first represented
> DTOs (as a "Value Object").
>
I will refer you to Bloch, et. al. Immutable objects are easier to code and to test.
> I suppose my reason for this would be that most of
> the work in other layers involves sending mutated
> data back. With your pattern this requires that the
> user, every single time, create a new object, copy
> the old data to the new, and then send the new object
> back.
>
You are asserting the 'new' keyword is onerous?
> Extra work with no gain.
>
I agree. There is an ever so slight overhead to creating a new, immutable object. However, limiting the possible states of an object, by definition, lowers its entropy and hence the possibilities one needs to test.
> > > The DAO can only have four methods, create,
> read,
> > > update and delete. I am a little confused here,
> > > because as I see it, we can only have these
> four
> > > methods to read/write from/to the TO.
> > >
> >
> > This is roughly what a database allows. However,
> > what of commonly used parent-child or foreign-key
> > relationships? You may retrieve an account holder
> > and his/her present balance 90% of the time in
> your
> > system. Do you want two separate TO's and DAO's
> > here? Or is this a case where a DAO can construct
> a
> > graph of objects in memory as an optimization?
> >
>
Yes. Issuing a single SQL query to fetch a parent child relationship is more efficient than fetching foreign keys in a parent table and querying for each child. Maybe we are in fact on the same page, maybe not. But I am referring to releationships such as many-to-many that pose difficulties to O/R mappers. The same would hold true for a design where each table row corresponds to an object.
> There are several other J2EE patterns for complex
> relationships.
>
> I am not sure I have ever encountered a need for
> those though.
>
Other than chaining various Collection classes, neither have I. However, a fairly rich set of relationships (hierarchical, sequential, dependent, etc.) can be constructed from these.
> >
> > > This would cause difficulties if we wanted to
> > > implement optimistic locking for example, where
> we
> > > wanted to check if a row had been changed before
> > > commiting the change (to prevent lost updates).
> > >
> >
> > I would not implement this myself. As Duffy has
> > alluded to, Hibernate and other O/R mapping
> > technologies maintain the state of an object and
> the
> > state when it was retrieved, allowing the
> framework
> > to update only modified fields when needed.
> >
>
> Interesting.
One of the best benefits that Hibernate offers out of the box, that and lazy loading.Though like all things, these too can be abused.
- Saish
Saisha at 2007-7-16 22:48:13 >
> > duffymo said
> >
> > > Personally, I think TOs are an anti-pattern, not
> a
> > > best practice. They came about because entity
> > beans
> > > have been a failure.
> > >
> > > I'm moving away from EJBs and towards POJO
> > > persistence using Hibernate. I think it's a much
> > > better solution.
> >
> > And to emphasize that this is duffymo's personal
> > opinion.
> >
> > One that others do not share.
>
> Joe's correct on both counts.
I do note that hibernate seems really interesting and additionally EJBs at least in the past were used far more than they should have been. At least so I believe, and I have seen others say it as well. (I believe I saw one person that basically stated that viewpoint was due to a lack of understanding of how to correctly use EJBs but that was a while ago.)
Others including myself have looked at other solutions because of this. However I don't consider that there is one single solution that completely obliviates the possibility that EJBs can be used though.
And even when I don't use EJBs I still use DTOs.
>
> I would like to hear Joe's response to the question
> about whether or not it's considered a good design to
> have two parallel class hierarchies, one for business
> objects with rich behavior and another of DTOs that
> mirror the attributes of the business objects without
> the behavior, solely for the purpose of ferrying data
> between layers. I've never understood the need for
> DTOs when the business objects themselves are
> perfectly capable of transporting their state.
Not sure what you mean.
Are you suggesting a framework where the business objects hold the DTO information themselvs?
And why would the business objects hold the same data as the DTOs rather than using the DTO directly? Or perhaps that is the answer you are looking for - the business objects use the DTO and do not hold the data directly.
We could also have a difference of opinion because the systems I work on are never solely accessed via java. Thus 'business logic' can not neatly be captured entirely in java classes. (Not to mention that even if it were the case I still wouldn't exclude all business logic from the database because in some cases it handles it better.)
> I'd also like to hear why you thought they were
> necessary in a non-EJB context. Thanks, Joe.
Because I want to transport related blocks of data between layers (not necessarily even database) in a convienent way.
> > I disagree. And apparently others do as well because
> > your model is the way that J2EE first represented
> > DTOs (as a "Value Object").
> >
>
> I will refer you to Bloch, et. al. Immutable objects
> are easier to code and to test.
That is nice - but again that does not match the current pattern. So certainly someone, and more than one I suppose, disagrees with that. And that change in attitude evolved over time (which means they didn't just forget about the non-mutable case.)
>
> > I suppose my reason for this would be that most of
> > the work in other layers involves sending mutated
> > data back. With your pattern this requires that the
> > user, every single time, create a new object, copy
> > the old data to the new, and then send the new
> object
> > back.
> >
>
> You are asserting the 'new' keyword is onerous?
>
There are 3 steps.
1. Create a new object
2. Copy the old data to the new object
3. Overwrite the changed data with the new data.
And 2 and 3 produce vastly more code than 1.
> > Extra work with no gain.
> >
>
> I agree. There is an ever so slight overhead to
> creating a new, immutable object. However, limiting
> the possible states of an object, by definition,
> lowers its entropy and hence the possibilities one
> needs to test.
>
Personally I don't feel that one should base a design on how much code one needs to write for the unit tests.
And certainly not for a DTO as it is a trivial object.
>
> Yes. Issuing a single SQL query to fetch a parent
> child relationship is more efficient than fetching
> foreign keys in a parent table and querying for each
> child. Maybe we are in fact on the same page, maybe
> not. But I am referring to releationships such as
> many-to-many that pose difficulties to O/R mappers.
> The same would hold true for a design where each
> h table row corresponds to an object.
>
Not sure who you are responding to here. But I am rather certain that the other patterns address the problem of composing.
> I do note that hibernate seems really interesting and
> additionally EJBs at least in the past were used far
> more than they should have been. At least so I
> believe, and I have seen others say it as well. (I
> believe I saw one person that basically stated that
> viewpoint was due to a lack of understanding of how
> to correctly use EJBs but that was a while ago.)
Or flaws in the spec, particularly in the case of entity beans. I think the understanding is that entity bean as an abstraction for a single row in a database table caused a lot of problems (e.g., n+1 query and excessive network traffic) that inspired core J2EE patterns like using stateless session beans to do database access.
> Others including myself have looked at other
> solutions because of this. However I don't consider
> that there is one single solution that completely
> obliviates the possibility that EJBs can be used
> though.
I like what Spring makes possible: POJOs without EJBs. But there's still a place in the world for stateless session and message driven beans. I'll have to see how EJB 3.0 sorts the rest out.
> And even when I don't use EJBs I still use DTOs.
> Not sure what you mean.
>
> Are you suggesting a framework where the business
> objects hold the DTO information themselvs?
Yes, that's what I mean.
> And why would the business objects hold the same data
> as the DTOs rather than using the DTO directly? Or
> perhaps that is the answer you are looking for - the
> business objects use the DTO and do not hold the data
> directly.
No, I'm saying that the business objects hold the data and provide the methods for operating on them. No need for DTOs to mirror their state.
> We could also have a difference of opinion because
> the systems I work on are never solely accessed via
> java. Thus 'business logic' can not neatly be
> captured entirely in java classes. (Not to mention
> that even if it were the case I still wouldn't
> exclude all business logic from the database because
> in some cases it handles it better.)
Yes, agreed. You're saying that sometimes you put what I'd call business logic in stored procedures, because it's far more efficient for the operations to be performed on the database server than to move it to the middle tier, massage it, and put it back. That's just a good tradeoff that isn't overly rigid about "architecture".
But to the degree that some business logic can reside in Java objects, I'd say that they don't need DTOs to operate. It's not a fait accompli. They aren't required.
> Because I want to transport related blocks of data
> between layers (not necessarily even database) in a
> convienent way.
This is the key argument in favor of DTOs, in my opinion. DTOs allow a clean separation of layers, so model objects don't have to appear in the user interface. A lightweight DTO is used to ferry data to the user interface, providing the additional advantage of making it impossible for the UI to perform business logic operations on the model objects. UI is for pure view, and DTOs make sure they stay that way.
So that's the tradeoff, in my opinion - is the benefit of cleaner layering worth the maintainence burden and "bad smell" of parallel business object and DTO packages? I say no, but that's my opinion.
%
The response to my "maintainence burden" comment is code generation. If you can use something like XDoclet to generate DTOs for you from existing business objects, then you're only left with my architectural quesiness and misgivings.%
Still don't like DTOs, but I'm listening.%
> > > I disagree. And apparently others do as well
> because
> > > your model is the way that J2EE first
> represented
> > > DTOs (as a "Value Object").
> > >
> >
> > I will refer you to Bloch, et. al. Immutable
> objects
> > are easier to code and to test.
>
> That is nice - but again that does not match the
> current pattern. So certainly someone, and more than
> one I suppose, disagrees with that. And that change
> in attitude evolved over time (which means they
> didn't just forget about the non-mutable case.)
>
I disagree. Where does that leave us now?
> >
> > > I suppose my reason for this would be that most
> of
> > > the work in other layers involves sending
> mutated
> > > data back. With your pattern this requires that
> the
> > > user, every single time, create a new object,
> copy
> > > the old data to the new, and then send the new
> > object
> > > back.
> > >
> >
> > You are asserting the 'new' keyword is onerous?
> >
>
> There are 3 steps.
> 1. Create a new object
> 2. Copy the old data to the new object
> 3. Overwrite the changed data with the new data.
>
> And 2 and 3 produce vastly more code than 1.
>
Steps #2-3 would only be true if state needs to be maintained between data retrieval and data update. I do not feel that this is required in the vast majority of transactions. Just an opinion, granted. Most database operations I write either take the parameters to update (and primary keys) in the signature or a 'request object' that consolidates these parameters if there are more than a handful. I have no need, normally, to fetch an object into memory and then manipulate dozens of fields within the same request to then immediately re-update the database. There will normally be a select request and then a subsequent user-initiated request to update the data.
> > > Extra work with no gain.
> > >
> >
> > I agree. There is an ever so slight overhead to
> > creating a new, immutable object. However,
> limiting
> > the possible states of an object, by definition,
> > lowers its entropy and hence the possibilities one
> > needs to test.
> >
>
> Personally I don't feel that one should base a design
> on how much code one needs to write for the unit
> tests.
>
> And certainly not for a DTO as it is a trivial
> object.
>
I assume you accept the premise known as Occam's Razor. Why would I code additional, unwarranted complexity into *any* object?
> >
> > Yes. Issuing a single SQL query to fetch a parent
> > child relationship is more efficient than fetching
> > foreign keys in a parent table and querying for
> each
> > child. Maybe we are in fact on the same page,
> maybe
> > not. But I am referring to releationships such as
> > many-to-many that pose difficulties to O/R
> mappers.
> > The same would hold true for a design where each
> > h table row corresponds to an object.
> >
>
> Not sure who you are responding to here. But I am
> rather certain that the other patterns address the
> problem of composing.
- Saish
Saisha at 2007-7-20 19:53:44 >
> Not sure who you are responding to here. But I am rather certain that the other patterns address the problem of composing.Sorry, myself actually. I mis-read the reply.- Saish
Saisha at 2007-7-20 19:53:44 >
> Sorry, myself actually. I mis-read the reply.> > - SaishSaish is addressing the wisest person present. 8) It's a great justification for talking to yourself.%
Can't take that honor. I've learned much and often from both you and Jschell. - Saish
Saisha at 2007-7-20 19:53:44 >
> The response to my "maintainence burden" comment is
> code generation. If you can use something like
> XDoclet to generate DTOs for you from existing
> business objects, then you're only left with my
> architectural quesiness and misgivings.
>
I always use code generation.
> >
> > There are 3 steps.
> > 1. Create a new object
> > 2. Copy the old data to the new object
> > 3. Overwrite the changed data with the new data.
> >
> > And 2 and 3 produce vastly more code than 1.
> >
>
> Steps #2-3 would only be true if state needs to be
> maintained between data retrieval and data update. I
> do not feel that this is required in the vast
> majority of transactions. Just an opinion, granted.
> Most database operations I write either take the
> e parameters to update (and primary keys) in the
> signature or a 'request object' that consolidates
> these parameters if there are more than a handful. I
> have no need, normally, to fetch an object into
> memory and then manipulate dozens of fields within
> the same request to then immediately re-update the
> database. There will normally be a select request
> and then a subsequent user-initiated request to
> update the data.
>
Probably 50% of the GUI screens that I am used to dealing with are used with updates. And those screens are more complex than the query screeens.
> > > > Extra work with no gain.
> > > >
> > >
> > > I agree. There is an ever so slight overhead to
> > > creating a new, immutable object. However,
> > limiting
> > > the possible states of an object, by definition,
> > > lowers its entropy and hence the possibilities
> one
> > > needs to test.
> > >
> >
> > Personally I don't feel that one should base a
> design
> > on how much code one needs to write for the unit
> > tests.
> >
> > And certainly not for a DTO as it is a trivial
> > object.
> >
>
> I assume you accept the premise known as Occam's
> Razor. Why would I code additional, unwarranted
> complexity into *any* object?
There is a quite a bit of difference between 'additional' and 'unwarranted'.
And it is unclear to me how this limits the tests that must be done - after all the functionality still exists.
Perhaps this is just a matter of working process. When I create database layers I generate everything. That includes unit tests.
So the only factor involved for me is how easy the external layer is to use (not to test.)
> Can't take that honor. I've learned much and often
> from both you and Jschell.
>
I find myself very uninteresting to talk to however. Either I am always in agreement or the flow of the arguments is always predictable.
And for some reason it makes people around me behave oddly when I started a heated conversation with myself.
> > Can't take that honor. I've learned much and
> often
> > from both you and Jschell.
> >
>
> I find myself very uninteresting to talk to however.
> Either I am always in agreement or the flow of the
> e arguments is always predictable.
>
> And for some reason it makes people around me behave
> oddly when I started a heated conversation with
> myself.
Nowadays it might mean you've got the latest Bluetooth wireless headset for your cell phone.
It's getting harder to spot the crazies.
%
I find myself very uninteresting to talk to however.Nah! Hasn't been my experience. Maybe not always agreement, but always interesting and engaging.- Saish
Saisha at 2007-7-20 19:53:44 >
Don't forget good looking.%
> Don't forget good looking.> Its that new hair color I am using - blue always suited me.
Add a Duke-like, blue pompador and you're styling.%
