CODEWITHSUNDEEP
c#asp.netasp.net-mvcentity-framework
Martin H.
Martin H.

Reputation: 1106

Best approach to share Entity Framework model between application layers

I want to create an asp.net application which has several layers (classic layer design): A business layer and a presentation layer. Data layer seems obsolete as EF does all the work.

So when I create the EF model in Business Layer, I cannot use the entities in presentation layer because I can't add data annotations for display and validation and so on (especially display attribute is typically a part of presentation layer). And it seems not very good to me to create copy all the data to similar "viewmodel"-classes in presentation layer.

So is there a good approach to create object context in business layer and having a shared "contracts"-assembly for the entities? Most samples that I have found place everything in one single assembly, which is not the best approach for more complex applications in my opinion.

Upvotes: 6

Views: 4521

Answers (4)

DK Chauhan
DK Chauhan

Reputation: 194

Here i have a good suggestion for you.

first of all divide you application in Layers

**SM.MVCApp**  :-  This is for MVC application 
**SM.Service** :- This layer is for holding the business logic (Interface & Class)
**SM.Data**    :- This layer is to interact with database using Entity framework (Repository & UOW)  
**SM.Entity**  :- This layer is responsible for having property in class that will be mapping with the table of database.

SM.Service example

public interface IStudent
{
    IQueryable<Entity.Student> GetAllStudent();

    Student GetStudentByID(Int32 StudentID);

    void CreateStudent(Student objStudent);

    void UpdateStudent(Student objStudent);

    void DeleteStudentvoid(Student objStudent);

    void SaveChanges();

    List<Entity.Student> SearchStudent(string Name, int Age, string EmailAddress, string CountryName);

    void MakeRelation(Entity.StudentCourceMap objMap);
}

Now showing How to create SM.Data Layer

  1. First of all Create DBContext class for creating database and tables
  2. Then create IRepository * Repository class for crud operations
  3. Then create UOW (Unit of work)

Upvotes: 0

Henk Mollema
Henk Mollema

Reputation: 46641

You should abstract EF away from your business layer, never use such frameworks directly. I usually create a generic repository interface and a generic EF repository (this is your data layer) which implements the interface. An IoC framework will take care of the injection of the right implementation at runtime.

Also, you are exactly describing the need of ViewModels in your presentation layer. They take care of showing only the information you need on the view along with the validation based on the data annotations. In the beginning they might look like duplicates of your domain entities, but in the end it will save you a lot of trouble, it's definitively the way to go.

Your business layer should result domain entities, in your controller you map them to your ViewModels. You could use AutoMapper for this.

You can check out this question and answer for more information about service/business layers and domain/view models.

Upvotes: 5

MrShoes
MrShoes

Reputation: 485

Create Data Transformation Objects (DTOs) that are exact copies of your Entities, except they only have the simple properties. Then use automapper to map between Entities and DTOs.

Upvotes: 1

Paritosh
Paritosh

Reputation: 11568

You can have layers like this.

  1. EF model layer project
  2. Business layer, which will interact with EF model
  3. Presentation layer, which interact with business layer, and you can give reference to EF model too, if needed

You can create your partial classes in EF model layer - for data annotation and all. So it can in turn - will be used in business layer also.

Upvotes: 2

Related Questions