We always followed an implicit guideline in the projects I've been:
- Put as many logic in the entity as long as
- it does not depend on an external service
- if it does, the service needs to be passed as parameter
- it does not carry a transactional boundary
- if it does it clearly belongs in the service layer
- it does not affect or relates to entities of a different context boundary
The operations on the service layer also match the business processes.
while the operations on the entities were related to its nature. I
can't help evoking the Account.Debit/Credit AccountService.Transfer as
the most obvious example.
On Tue, Jan 6, 2009 at 1:14 PM, Michele Cantelli <[email protected]> wrote:
>
>
> hammett wrote:
>
>> Also, replicating dependencies on a distinct player feels like a
>> smell. I for one hardly have my repositories having dependencies.
>> But I agree that in the great scheme of things, it's the less
>> problematic approach..
>
> So what is the right approach for you in my previous example? Moving
> out the behaviors from the entity to a service?
>
> >
>
--
Cheers,
hammett
http://hammett.castleproject.org/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
