Should a domain object know how to save itself

[tara]

Should a domain object know how to save itself?

To elaborate this is what I mean.

Objects knows how to save its self.

After the object has been loaded with data and validated
MyObject.save() is called. The save method directly calls the DAO and
passes itself to the DAO for saving.

Object saving handled by the manager/service

After object has been loaded and validated myManager.save(MyObject) is
called. The manager mediates all interactions with the DAO and passes
the object to the DAO for saving.

At the moment I feel that myObject should know how to validate itself
(since this is buisness logic) but should not know how to save itself.

What do other people think?

[Thomas Messier]

I feel that the second option (saving handled by service) separates concerns
better, but I don't think there's really a right answer. For example, using
the Active Record design pattern the object saves itself. A lot of people
like that approach and Ruby on Rails uses it. Seems to me it would make your
objects more tightly coupled with the data layer, but I guess depending on
your use case it may not be an issue. I'm sure others can chime in with
better explanations.

-TM

--
You received this message because you are subscribed to the Google Groups
"Object-Oriented Programming in ColdFusion" group.
To post to this group, send email to coldfu...@googlegroups.com.
To unsubscribe from this group, send email to
coldfusionoo...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/coldfusionoo?hl=en.

[tara]

Yes totally agree that there is not really a right answer. But as you
say having the object save itself tightly couples it to the data layer
which I don't like.

But in some use cases having the object save itself can be an
advantage. So I suppose maybe another question to ask is, which
approach is OOP purity vs pragmatic OPP.

On Mar 14, 12:49 pm, "Thomas Messier" <thomas.mess...@gmail.com>
wrote:

[Daniel Cook]

I'm an OOP noob, but I've had a taste of Java.

I'm loosely aware of what you are discussing and would like to throw in
my 2 cents, which may not help at all!

http://en.wikipedia.org/wiki/Hibernate_(Java)
<http://en.wikipedia.org/wiki/Hibernate_%28Java%29>

Hibernate for JAVA seems popular, so perhaps a good option is to do as
they do.

[John Whish]

For simple objects then having an object that can save itself is
perfectly valid (Active Record uses it). However, you may want to
consider if your object will be composed of other objects (for example
a Product could have many options), so you would then have to consider
if when you save the product you also save the Options. This could get
complicated quickly and lead to brittle code. It is also usually
harder to test when using Active Record as you are tightly coupled to
the database.

As long as you have thought about the pros and cons of each approach
then do which ever suits your project/style.

[Mark Mandel]

In a purely academic sense, objects really shouldn't know how to persist themselves - persistence should be transparent.

Objects should be representations of real world objects, and real world obejcts don't have to tell the world they live in 'hey, make sure I don't slip out of existence' all the time (or there may be some that do, but I think they would be few and far between).

I tend to lean this way, but I prefer a a fairly academic view on these things.

Mark

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

cf.Objective(ANZ) - Nov 17, 18 - Melbourne Australia
http://www.cfobjective.com.au

Hands-on ColdFusion ORM Training
www.ColdFusionOrmTraining.com

[Baz]

The poster has the data layer already separated - the question can be boiled down to simply: "where should this line of code be written: myDAO.save(myObj), in the service or in the object itself?" It's totally a preference thing. I like how the code reads when it's within the object itself, and I find it handy having the logic ported along with the object so I don't have to remember how to invoke a CRUD. Really though you'll always get a 50/50 split on this.

Baz

[Sean Corfield]

Since you have myManager.save( myObject ) already, then
myObject.save() is just a convenience and I think it's a good one. A
big benefit is that you may not need code to depend on the service
when it saves the object - it just tells the object to save itself
instead of needing references to your service all over your code.

In particular, your object doesn't really know how to save itself, it
knows there is a related service and that service knows how to save
the object. So you're not breaking your intuition / feeling here...

[Mark Mandel]

Well, it's not as if I walk around going 'oooh, make sure I stay in existence NOW' every 15 minutes or so ;o) I just stay in existence (unless we start getting into Quantum Physics) by the nature of the system I am in.

But at the end of the day, I think it comes down to an academic OOP position vs a pragmatic one, and each has it's own pros and cons.

Personally, I find that if an object needs to know how to save itself, then each object has to know about it's correlating service, which not all objects will need to if they don't have a save() object... but anyway, that's my opinion, I can definitely see pros and cons both ways.

Mark

On Tue, Mar 15, 2011 at 12:07 PM, Sean Corfield <seanco...@gmail.com> wrote:

In particular, your object doesn't really know how to save itself, it
knows there is a related service and that service knows how to save
the object. So you're not breaking your intuition / feeling here...

[tara]

Thanks to everyone for your replies

Agreed this comes down to academic OOP VS a pragmatic one.

If we now expand the myObject to also have other child objects myOptionsObject and myAddressObject. Then byy having the object save itself via the DAO we can ripple the save down to all the children objects.

The other approach is to have a facade which handles the saving via the respective managers and then to the DAO's. The one advantages I can see is that we can group the save calls in a transaction. But it does lead to quite a fat facade.

Are there any other advantages or disadvantages in these two approaches? Is it fine to end up with a fat facade handling the saving.

Or is is just down to which approach you favour depending on personal preference and the problem being solved?

Tara

[Nathan Strutz]

I would say it comes down to personal preference. Some people like the feel of the active record pattern, some think it's dirty. I would say just make sure to keep it consistent across your application and follow your best practices as well as you see them.

For active record, I think it's ok if your beans know that they are saved, but it's not ok if they know how they are saved. One way or the other, just make sure you are happy with the design, and make sure you can teach it to another developer within 90 seconds (the simplicity test).

Once you lay it out and live with it for a while, maybe even a year or more, you'll see if there are flaws in your design. The problems will become self-evident. It always happens, so just be ready for it. Sometimes it takes years to see how a system should have been designed. Always prepare to make time for refactoring on this level.

nathan strutz
[http://www.dopefly.com/] [http://hi.im/nathanstrutz]

--

[Bob Silverberg]

On Tue, Mar 15, 2011 at 10:33 AM, Nathan Strutz <str...@gmail.com> wrote:

> Once you lay it out and live with it for a while, maybe even a year or more,
> you'll see if there are flaws in your design. The problems will become
> self-evident. It always happens, so just be ready for it. Sometimes it takes
> years to see how a system should have been designed. Always prepare to make
> time for refactoring on this level.

That is an excellent point, Nathan. Sometimes we spend too much time
trying to figure out the best design, only to discover down the road
that there were issues with the design we chose. If your design
follows the proper design principles, it should be no problem to
refactor it in the future when you discover a better design. Bringing
that back to this discussion, as pretty much everyone has said, as
long as your object doesn't know how it's being saved (i.e., all of
that logic is encapsulated in another object) then you'll be able to
refactor in the future, so just choose whatever feels right to you at
the moment.

Cheers,
Bob

--
Bob Silverberg
www.silverwareconsulting.com