Using Entity Framework, non-MVC project, need help with class structure

Question

I'm working on a very large non-MVC project utilizing Entity Framework for database access. This is a new project, so we've got a wide-open canvas for development.

The conceptual problem I'm running into is how to model the layer just above the EF Models.

At the database level I've got a Customer, Order, and Item table so there's a model for each.

Now I need to describe what the Customer can do. For example, ultimately I want to say something like:

 Order newOrder = customerObject.CreateOrder(itemList);

Where does the method CreateOrder live?

My gut tells me that there's a sub-class of the Customer Model that has the methods needed by the Customer. With an interface to that class up front to keep the cross-dependencies between modules low.

But this sounds too easy to be the correct way.

Some related questions I've found, but didn't exactly apply are:

• Different kind of problem, and the proposed solution is to make the models into partial classes
• This is discussing the full layer management, and obviously a smaller problem

Answer 1

The one that I have used which worked quite nicely. Basically used repositories to house the methods called. Everything was divided into:

• Context: Sets up your db context using the below, implements System.Data.Entity.DbContext. It contains DbSet's of your entities. So a sample will look like below:

  public DbSet<Customer> Customers { get; set; }
  
  protected override void OnModelCreating(DbModelBuilder modelBuilder) 
  {
      Database.SetInitializer<CustomerDatabaseContext>(null);
  
      modelBuilder.Configurations.Add(new CustomerConfiguration()); 
  }
  

• Entities: Literal mapping of db object

  public class Customer
  {
      public long Id {get; set;}
  
      public string Name {get; set;}
  }
  

• Configurations: Setting up your entity

  public class CustomerConfiguration : EntityTypeConfiguration<Customer>
  {
      public CustomerConfiguration()
      {
          this.Property(x => x.Id).HasColumnName("CustomerId");
          this.HasKey(x => x.Id);
          this.Property(x => x.Name);
      }
  }
  

• Repositories: Holds all the methods e.g.

  public Customer GetById(long identity)
  {
      using (var context = CustomerDatabaseContext.Start())
      {
          return context.Customers.FirstOrDefault(x => x.Id == identity);
      }
  }
  

• The repositories are initialised in code and used e.g.

  var customer = this.repository.GetById(request.CustomerId);
  

Answer 2

Everyone appears to be on the repository train. Given EF is already a repository, I would push to house business logic on a service layer. A service doesn't necessarily have to be in a new library (though it could), but does provide that additional logic atop the base entities. To illustrate:

public interface IOrderService : IDisposable
{
    Order Create(Customer customer, params Item[] items);
}

public class OrderService : IOrderService
{
    private DbContext context;

    public OrderService(DbContext context)
    {
        Contract.Requires(context != null);

        this.context = context;
    }

    public Order Create(Customer customer, params Item[] items)
    {
        Contract.Requires(customer != null);
        Contract.Requires(items != null);
        Contract.Requires(items.Length > 0);
        Contract.Ensures(Contract.Result<Order>() != null);

        Order order;

        //
        // Business logic building order;
        //

        return order;
    }
}

Then usage would look something like:

// -- Existing variables --
var db = /* your EF context */;
var customer = /* your targetted customer */;
var items = /* the items to be added */;
// -- /Existing variables --

// Executing against new service
var orderSvc = new OrderService(db);
var newOrder = orderSvc.Create(customer, items);

Commentary

All a repository pattern does (on top of an ORM) is abstract out the API that's already there. Now you're duplicating efforts, and, a lot of the time, losing some very cool features of the ORM itself (this is why you chose the ORM over using SqlConnection I would presume...). Sure, you might change out your ORM months/years from now, but is it worth the up-front effort? (That's for you to decide)