ASP.NET MVC Entities, DTO, Business objects, ViewModels? How do i manage this?

9
votes

I'm very busy with the architecture of a new MVC application, but i'm getting very confused about how to manage different type of objects. The confusion is about the relation between entities, business objects and viewmodels. I 'm going to describe my confusion with an example:

I've set up my web application with different projects: MVC frontend, BLL, DAL, Common things etc.

Let's say i have a view with a List of bikes. I want to display the bike details like color, size, manufacturer. But in my database, the Bike and Manufacturer are two different tables, so in my Entity Framework context, these are also two different classes.

So i have these two entities Bike and Manufacturer. But in my business needs, i think they need to be a single object, which i can manipulate or use in business logic. Then there is my view, which needs a (View)Model. That should also be a combined ViewModel with properties from different tables.

How do i handle this? Do i need to get the Bike and Manufacturer object from my DAL, and create a business object from it in my BLL, and after doing some business logic, should i create a ViewModel from it in my controller? Or does my DAL need to return a combined business object? Or can i use the entity object as business classes? Or can i also use my business object as a ViewModel?

I hope that my problem is clear and that anyone can give me a good advise about which object are needed and how, where and when the different types of objects are created, and in which layer this classes should go...

5
c#asp.net-mvcentity-frameworkarchitecture
Have a read: blogs.msdn.com/b/simonince/archive/2010/01/26/… – Bhushan Shah
@AmateurProgrammer thank you, this clears out at least the ViewModel part of my confusion. I see i can do mapping from Business Objects to ViewModel in my controller. But what about the relation between business objects and entities. Are they the same classes?? – Jeroen1984
If by 'entities', you mean EF entities, then no. Your business entities are fundamentally logically different than your database/ORM entities. You are not going to apply your business logic directly on objects you get from the database. You would preferably map them to your business objects first. So basically an extra layer would come in. – Bhushan Shah

5 Answers

1
votes

You can have a custom business entities, that will be referenced in your views.

In you business implementation you can have some mapper that will map your Entity Framework entities to your custom business entities, you can use Automapper to achieve this.

I hope this will help.

1
votes

The answer to your question is easy. There is NO relationship between your different layers of models. They are completely isolated, and do not refer to each other. Not at all. As such, there is nothing to be confused about.

You have code in different parts of your layer that maps between two layers UI->Business and Business->Data, but that should be the extent of any interaction between them.

1
votes

You should have some common functionality where you'll have all your mapping for your Business and EF entities.

and in your implementation you will map just ask your mapper to provide actual entities.

There should be some common class that will create mappings for you.

Something like this

public static void CreateTestMapping() { Mapper.CreateMap<DataAccess.Entities.Test, Business.Entities>() .ForMember(s => s.Col1, d => d.MapFrom(t => t.Colabc)) .ForMember(s => s.Col2, d => d.MapFrom(t => t.ReferenceTable.RefTableCol1)); }

and in your business implementation you'll use this mapping to convert Business.Entities to EF.Entities and visa-versa

Mapper.Map<Business.Entities.Test, EF.Entities.Test>(source, destination);

1
votes

What i would do is:

Your DAL returns a List<Bike> and a List<Manufacturer>.

Then your Business Layer should manipulate these and return to asp.net MVC an appropriate object.

For example a List<Manufacturer> which contains for every item a List<Bike>.

Create the appropriate ViewModels and add Controller logic to manipulate them BUT DO NOT do any core business manipulation there, just UI manipulation to suit your views.

Also i would recommend NOT to bind your UI with your DAL.

Keep your UI project referenceing the common libraries + Business layer project.

Let the business communicate with the DAL.

0
votes

IMHO, part of confusion comes from the fact that you "can't" break all links between your projects even if you want for "design" and separation of concern reasons.

Well, in fact you can (and may be should) break, but the cost is, at least: lost intelisense and/or marshalling coding.

At the end, your projects are linked at least by a convention. One project expects a behavior from the other. If you publish weather data, you expect your DAL to provide weather data and not financial data, even if it should be wise to handle the case.

At least one project must expose an interface/DTO, and the other must implement this interface.

Usually and humbly, I try to make the business logic independent : business can be built without reference to any other project (PLEASE: note I speak of project not of layer). So My abstract classes or interfaces are in the business or domain project. Why: the most probable changes are GUI technology changing or persistence technology changing, so if you want to interact with me here are the contracts (false friend here).

So the web site (or any GUI) project references the business project and the DAL project, the DAL project references the business project.

  • The controller get the data from the DAL and provide it to the domain/business logic
  • The controller then provide the unattached result to razor, and/or persist the result by the DAL.

BUT imho, evil starts when you stop mastering the scope of your context (DbContext, ObjectContext,...). Other saying try to avoid providing attached object to Razor.