Eric Evans (the author of Domain-Driven Design, which Fowler references) would not recommend that a User object knows how to store itself in a database. He would recommend creating a UserRepository class which represents the "set" of all of the User objects in the system. >From the outside, the UserRepository should look and feel like an in-memory collection of User objects. Now, that repository could be implemented as exactly that, an in-memory collection. Or, more likely, it would be implemented using something like Hibernate (see my article at TheServerSide.com for an example of this), JDO, or just plain JDBC.
-----Original Message-----
From: Nick Stuart [mailto:[EMAIL PROTECTED]]
Sent: Thursday,
April 21, 2005 11:27 AM
To: [email protected]
Subject: Re:
Anemic Domain Model
So basically he is saying that the
application layer should do nothing more then call the Domain Layer objects
which do all the work? In other words, not only does the Uesr object store the
data, but also knows how to do everything else with the user as well right?
(save to the database, load, delete, etc)
I dont know, but that just
feels wrong to me. The data is just that, data. I treat my simple POJO beans
like that and everything seems to work out fine for me. My services are
responisble for loading, saving, creating the data and thats it. What woud I
gain by putting that in the User itself? He never mentions what you gain, just
that you loose a lot of OO usuability (but never mentions specifics).
His
so called anti-pattern goes against almost everything I've read or been taught.
But thats just me.
-Nick
On 4/19/05, Luke Renn
<[EMAIL PROTECTED]> wrote:
> Hello List,
>
> I was
just reading this:
> http://www.martinfowler.com/bliki/AnemicDomainModel.html
and was
> wondering what Hivemind users think about it.
>
> Do
you agree? If not, what kinds of tasks to you leave for your
>
services, and what kind of logic do you reserve for your domain.
>
>
--
>
Luke
| PGP: 0xFBE7D8AF
> [EMAIL PROTECTED] | 2A44 9EB2 F541 C1F2 D969
56E3 8617 5B7F FBE7
> D8AF
>
>
---------------------------------------------------------------------
> To
unsubscribe, e-mail: [EMAIL PROTECTED]
> For
additional commands, e-mail:
[EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To
unsubscribe, e-mail: [EMAIL PROTECTED]
For
additional commands, e-mail: [EMAIL PROTECTED]
