0

In older web projects that I worked on, we used to create models in DAL, add reference of DAL in Business Logic Layer (and reuse models from DAL as they would be available with reference of DAL), Add reference of BL in Service (again reuse models). Entities were available transitively in all successive layers.

In a MVC project with multiple layers, Models are often added in a separate class library project and referenced across all layers like DAL, Business Logic, Service, FrontEnd etc; Even though they are transitively available.

Is there any specific reason to do this? Why shouldn't we bind Models available through service in frontend like below

@model List<TestSolution.TestServiceRef.Employee>

instead of 

@model List<TestSolution.Models.Employee>

What is the advantage of referring models separately in all layers over using it from the reference of another/previous layer?

Cœur
  • 37,241
  • 25
  • 195
  • 267
poojas
  • 1
  • 4

1 Answers1

0

I don't have a lot of MVC experience (as far as ASP.Net MVC), but as I understand it the Model in MVC is just a representation of the data structures as the coded understands it (i.e. at runtime) - and isn't necessarily the underlying data itself (i.e. database).

If you have a concept that you want to represent in the UI, then obviously the UI needs to know what that concept is - hence referencing it at that level (and other such as the business logic, etc). Pre MVC there was an approach / architecture I followed where the "model" was just a bunch of POCO's (plain old class objects - .e. really simple dumb classes or structs).

These POCO's could go into a an assemply/project like MyApp.Common from where you could safely reference them in any other project / layer of the architecture (UI, Logic, DAL, etc). This allows all layers of the application to "talk the same language", so to speak.

I did a proper write up of this architectural style (which is not MVC, but shares some concepts), here: https://morphological.wordpress.com/2011/08/29/5-layer-architecture/

Adrian K
  • 9,880
  • 3
  • 33
  • 59