Reputation: 732
On a 3 tier application, I am using my business entities to generate the dbSets
on my dbContext
.
On business layer:
public class User
{
string name {get;set;}
}
On the data layer:
public context:DbContext
{
public DbSet<User> Users {get;set;}
}
My question then is how can I encapsulate logic on the entities? I could use extension methods, but I also want some properties, and I don't want them to leak outside the domain layer.
Upvotes: 1
Views: 1243
Reputation: 4203
With this type of architecture, it's best to create Interactors that contain all the business logic. That way your domain models (such as User) can be very lightweight.
There are two common ways to go about create Interactors. One way is to create a Service object. The service can offer all use cases and perform all business logic. This approach works better for simple domain models and for small/medium applications.
Service Interactor Example:
public class UserService
{
public void ChangeUsername(User user, string name)
{
... business logic ...
}
}
Another common way to encapsulate business logic is to create an object per use case. Whenever you add a new operation, simply create a new class. This requires more initial work and a better grasp of enterprise architecture, but results in a very scalable solution.
Use Case Interactor Example:
public class ChangeUsernameOperation
{
public void ChangeUsernameOperation(User user, string name)
{
... business logic ...
}
}
Upvotes: 5