Question

Let’s say I am using a traditional 3-layer application (UI-BLL-DAL) in a .NET application, where would the busniess rules be applied in reference to the generated Entity class? Would you extend the entity with a partial class and add the rules there, pass the Entity up to the BLL map to a busniess object and process rules in a separate class, or something entirely different? What has been the common practice thus far?

Thank you,

Answer 1

Don’t put business logic in your entities. Entities exist to map the DB interface to the application and, hence, aren’t really even objects.

Also, putting business logic in your entities makes them fat and confusing. You’ll have some properties which exist for DB mapping. Others which represent runtime concerns. Some methods you can call in an L2E query. Some you can’t. It’s a mess. Also, it makes your business logic deeply tied up in EF code, which is a bad separation of concerns.

We write services for business processes. Each service is constructor-injected with repositories for the data it needs. The business logic is totally separate from the EF mapping concern. It might not even use EF types. For example, you can write code like:

var q = from l in Context.Animals.OfType<Lemur>()
        select new LemurDto
        {
            Id = l.Id,
            IsKing = l.Name.Equals("Julien XIII")
        };
var service = new LemurCountService(q);
return service.Inventory();

So in this case the LemurCountService is totally independent of the EF.