Question

I try to put as much business logic as possible in my Domain Model.

Every time MyEntity is updated, I want two things to happen:

1. Send a message to the user who created it
2. Check if the changes apply to certain business rules

If the entity is not a child of an aggregate root.

Normally I would get the specific entity from the repository. Change the entity, and persist it
back to the DB using MyRepository.Save()

In this case I’d have to put the business logic in my application or in the DAL, not in the Domain Model. I’m trying to avoid using a business logic layer unless absolutely necessary, but I can’t seem to fit this in unless I make a method called MyEntity.Update() or something like that but I have a feeling that is not the right way to do it.

Answer 1

First let me state, I am not against Repository patterns. I recently used one successfully on a project.

I would say exercise caution … and if you can’t encapsulate the requirements in your objects your OO approach might need to be looked at again. Introducing a Data Access layer for the purposes of doing other things seems to be a code smell. I have used a Service Layor to receive requests and manage transactions and versioning however not for additional things like validation and so on. Potentially your service layor could look like the following.

    public enum UpdateResult
    {
         Success,
         NoMyEntityFound,
         StaleData,
         InvalidRequest
    }


public class MyService
{


     ...
     ...


     public UpdateResult Update(...)
     {
          ...Start Tran
          ...Load var m = MyEntity
          ...do the bare minimum here 
          ...m.Update()
          ...Commit Tran

          return UpdateResult.Success;
     }

}

Having said all that a cautionary tail on repositories

http://ayende.com/blog/3955/repository-is-the-new-singleton