CODEWITHSUNDEEP
modeln-tier-architecture
Jonn
Jonn

Reputation: 4661

Of Models / Entities and N-tier applications

I've only discovered a month ago the folly of directly accessing entities / models from the data access layer of an n-tier app. After reading about ViewModels while studying ASP.NET MVC, I've come to understand that to make a truly extensible application the model that the UI layer interacts with must be different from the one that the Data Access layer has access to.

But what about the Business layer? Should I have a different set of models for my business layer as well? For true separation of concern, should I have a specific set of models that are relevant only to my business layer so as not to mess around with any entities (possibly generated by for example, the entity framework, or EJB) in the DAL or would that be overkill?

Upvotes: 0

Views: 195

Answers (2)

Dave Swersky
Dave Swersky

Reputation: 34810

ASP.NET MVC is well served by the Model-View-ViewModel (MVVM) way of doing things. This means that each view gets ONE and ONLY ONE ViewModel, which is a custom-shaped Model that is dedicated to serving that View.

For example, if you have an Orders view that needs some OrderDetail and Customer data, create a ViewModel that exposes only the data from those Entities required by that View. The ViewModel serves to aggregate data together from multiple (or one, as necessary) entities.

Your Entities and business logic sit "under" the View/ViewModel layer and should be unaware of its implementation.

Upvotes: 0

Tejs
Tejs

Reputation: 41256

Yes, you can. However, that particular solution complicates your code and leads to a bunch of POCOs that have similar properties and data, which is pointless.

The major point, however, it just to have a separation of the object used to render your view, and the object you use to represent the data.

Upvotes: 1

Related Questions