Should i use partial classes as business layer when using entity framework?

Question

I am working on a project using entity framework. Is it okay to use partial classes of the EF generated classes as the business layer. I am begining to think that this is how EF is intended to be used.

I have attempted to use a DTO pattern and soon realized that i am just creating a bunch of mapping classes that is duplicating my effort and also a cause for more maintenance work and an additional layer.

I want to use self-tracking-entities and pass the EF entities to all the layers. Please share your thoughts and ideas. Thanks

Answer 1

I had a look at using partial classes and found that exposing the database model up towards the UI layer would be restrictive.

For a few reasons:

1. The entity model created includes a deep relational object model which, depending on your schema, would get exposed to the UI layer (say the presenter of MVP or the ViewModel in MVVM).
2. The Business logic layer typically exposes operations that you can code against. If you see a save method on the BLL and look at the parameters needed to do the save and see a model that require the construction of other entities (cause of the relational nature the entity model) just to do the save, it is not keeping the operation simple.
3. If you have a bunch of web services then the extra data will need to be sent across for no apparent gain.
4. You can create more immutable DTO's for your operations parameters rather than encountering side effects cause the same instance was modified in some other part of the application.

5. If you do TDD and follow YAGNI then you will tend to have a structure specifically designed for the operation you are writing, which would be easier to construct tests against (not requiring to create other objects not realated to the test just because they are on the model). In this case you might have...

   public class Order
   { ...
       public Guid CustomerID { get; set; }
   ... }
   

Instead of using the Entity model generated by the EF which have references exposed...

public class Order
{ ...
    public Customer Customer { get; set; }
... }

This way the id of the customer is only needed for an operation that takes an order. Why would you need to construct a Customer (and potentially other objects as well) for an operation that is concerned with taking orders?

If you are worried about the duplication and mapping, then have a look at Automapper

Answer 2

I would not do that, for the following reasons:

1. You loose the clear distinction between the data layer and the business layer
2. It makes the business layer more difficult to test

However, if you have some data model specific code, place that is a partial class to avoid it being lost when you regenerate the model.