Question

My basic solution structure in every project is:

• Dal – Data access layer
• Business logic which divided into two sections one is business entities and the second is business logic

So in my current practice my entities includes only data members and properties and NOT CRUD operations.
It’s always felt wrong to put CRUD operations within the Entity. My thought was..

• It’s OK which entity deletes himself?
• It’s OK which entity adds
  himself to the DB?

So i moved the CRUD operation to another library (Class) which represent my business Logic.

For example let say that we have an foo entity

public class Foo
{
    //Data Members
    private int _id;
    private string _Name;

    //Properties
    public int ID { get; set; }
    public string Name { get; set; }
}

So for this entity i will create a FooLogic library (Class) which holds all CRUD operations Like:

• Add a New Entity
• Delete an Entity
• Get a list of entities
• Update an entity
  And so on..

So what i am asking is:

1. It’s right practice not to put the CRUD operations within the entity object?
2. If so, What methods should i put in the entity himself of course beside “Print details”
3. It’s Ok to have business Logic library (Class) for each important entity?

Answer 1

I can’t speak for what is absolutely correct in every circumstance (because nothing is, but also because I’m not a true “enterprise”-y developer), but…

1. Database/entity operations, such as insertions and updates are usually handled by a Repository class that encapsulates every database operation. Repository methods accept or return an entity class object which represents a database record (or records, if you have a good ORM). An entity object should be a POCO and contain no logic that ties itself directly to the database – this allows you to swap out the default Repository implementation for a mock, which makes testing so much easier.
   • Note that in the .NET world, your EF DbContext is a repository already. You do not need to reimplement the Repository pattern yourself.
2. Only accessors and mutators that operate on the entity object’s in-memory state. This includes trivial properties, but also things such as Person.GetFullName() which would concatenate the Person.FirstName and Person.LastName fields, for example.
   • So you would not have a method on your Person class called SendEmailTo() because that is not really an operation on the Person, but on your e-mail system.
3. Generally speaking, no. Your business logic should happen in response to incoming messages (such as a client event, or a polling timer) and is a separate concern from mere repository tasks.

Here’s how I’d implement a simple CRM (with a single entity, the Customer):

An entity class DBCustomer:

(presumably generated by Entity Framework) that represents a customer stored in the database.

class DBCustomer {
    public String FirstName { get; set; }
    public String LastName  { get; set; }
    public String FullName  { get { return this.FirstName + " " + this.LastName; } }
}

A repository

The Entity Framework DbContext is your repository object so no work needs to be done here.

Business logic

…such as a WCF message handler – but sometimes the logic is really simple, especially when the business action corresponds directly to a database action, e.g.

StatusCode Customer_Add(CustomerXml newCustomerXml) {
    DBCustomer newCustomer = createNewCustomerFromXmlMessage( newCustomerXml );

    using( MyDbContext dbc = CreateDbContext() ) {
        dbc.Customers.Add( newCustomer );
        dbc.SaveChanges();
    }

    return StatusCode.Success;
}

Now you might notice that there seems to be a lot of useless layers here – I could use the CustomerXml class (which represents a deserialized formerly-XML-formatted message) and then call the EF context methods directly from the WCF message event handler, and it would would work for very trivial projects, however as projects grow you’ll see you need to add custom logic at every step, and suddenly things get unmanageable quickly.

So for a simple data-driven website then a simple “do everything in the ame layer” approach would work fine, but an “entperprise” application with lots of niggles in the specification is going to need these extra layers.