1
votes

I have created a solution with 4 Layers (4 projects):

  1. Entity Framework Layer (EFL)
  2. Data Access Layer (DAL): all of queries and CRUD operations
  3. Business Logic Layer(BLL): my business terms and calling DAL classes
  4. MVC Layer (MVCL)

I added reference of EFL to all layers and added DAL reference to BLL and reference of BLL to MVCL layer. enter image description here

My problem is my entity classes that are in EFL layer. I can add a reference of EFL in MVCL and use these classes in controllers and views but what about MVC model if I do that?

I create all the EFL classes in model folder of MVC but I didn’t use MVC model.

I just used EFL class. Is it true? Or maybe I should create some function to convert EFL and MVC model classes to each other and then I just use MVC model classes?

Which architecture is true here?

1

1 Answers

2
votes

My problem is my entity classes that are in EFL layer. I can add a reference of EFL in MVCL and use these classes in controllers and views but what about MVC model if I do that?

Create a common library (new project). This project should contain your interfaces and common entity classes (like the models used in EF). This project should have 0 dependencies on your other projects, your other projects can then reference this project. This will you to reuse your entity objects across your layers (if needed) and also allow you to define common interfaces on your services so you can expose those from your layers instead of your concrete implementations.

I just used EFL class. Is it true? Or maybe I should create some function to convert EFL and MVC model classes to each other and then I just use MVC model classes?

Whether or not to use a EF model across your layers and into your top presentation layer depends on the model and how it is used. Some times this is fine especially with very simple models or in a simple project. Other times it is not and you will want to convert the model to something that more closely mirrors how the end actor will be manipulating it (including validation and possible dependencies). It usually situation specific unless you specify some common standard across your solution.