Reputation: 1324
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:
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.
Upvotes: 2
Views: 1164
Reputation: 2358
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
Upvotes: 1