0

I have an architectural issue. I'm trying to build an ASP.MVC web application using dependency injection to decouple data access layer. The problem is - models.

Basically I have two projects in solution. The first is the MVC web application and the second DLL which is data access layer. DAL has some interface, its implementation and models generated by Entity Framework, also some additional models - search criteria and results. MVC has a property in a base controller where the DAL is injected using Ninject.

My concern is - how should I handle the models?

Reason why I use the dependency injection is decoupling DAL from main web application. So if I properly understand the idea DAL should be easy attachable/detachable. But if I'd use DAL's models in MVC controllers and views it will be completely dependent on even slightest changes in the DAL.

I've created the models in MVC which duplicates Entity Framework generated models so I can use those MVC models in MVC and just before calling DAL methods I map them to the DAL models using AutoMapper, so the DAL models are used only in the controllers and coupling is looser. But it seems to be still dirty, far from elegance solution.

What do you think? Is there any way to handle it in a smarter way?

Arkadiusz Kałkus
  • 17,101
  • 19
  • 69
  • 108

2 Answers2

2

You are correct. it's not a good idea to pass your DB models directly to the View Engine. That is not recommended because of a zillion of reasons (including performance, potential information leak, coupling etc.).

I don't think mapping your DB Models to View Models 1:1 is a good idea. The recommended way is to have the view models represent only the bare minimum that you need in a certain view. There is some overhead to constantly map your data models to your view models correctly to extract exactly what you need on certain views, but that is necessary evil to get clean and lean view models.

Here are some advices how to use View Models in ASP.NET MVC:

ASP.NET MVC - How exactly to use View Models

To Quote Chris Pratt from the thread above:

This is where view models come in. MVVM (Model-View-View Model), a somewhat parallel pattern to MVC, recognizes the inherent issues in a one-model-to-rule-them-all approach. I won't go into much detail here, because MVC doesn't use this pattern. However, most ASP.NET MVC developers have co-opted the View Model of MVVM. What you essentially end up with is a database-backed entity (the traditional model) and then usually many different view models that represent that entity in various states. This allows your model to contain the business logic that's relevant to persistence while the view model(s) contain the business logic relevant to displaying, creating and updating that model.

Community
  • 1
  • 1
Faris Zacina
  • 14,056
  • 7
  • 62
  • 75
1

Put your models in a Common.dll which both the UI and DAL reference. If your DAL changes, you can make it return the existing models in Common without changing your UI. Or if you UI changes your new UI can just reference the Common.dll and work with existing models. If you later need to add an API, API will only reference the Common.dll (or whatever you want to call it).

Edit: This is assuming you don't return EF models from your DAL to your UI. UI uses view models, DAL uses EF models, AutoMapper maps between the two.

artm
  • 8,554
  • 3
  • 26
  • 43
  • Very good idea. Concluding - I was trying to decouple too much ;). The thing I was not aware is simple - models are part of contract, part of interface so they mustn't be easily changeable. But there's something I'm not sure. Please, correct me if I'm wrong - when I moved models to common I should - in case of using EF - duplicate entity generated models and map them in DAL, right? I mean - DAL interface should use models from common (even if it's simply entity/table model). – Arkadiusz Kałkus Sep 25 '14 at 08:52
  • 1
    Like the answer below says "There is some overhead to constantly map your data models to your view models correctly to extract exactly what you need on certain views". DAL internally uses EF models, like a User data model, with late binding and loads of properties, and virtual collections, what not, but UI requests a UserEmailViewModel (which resides in Common.dll), DAL will map from its data models a UserEmailViewModel and return only UserName and Email. So yeah, DAL interface should return and take models in Common.dll. How it maps them is up to the DAL, UI doesn't care. – artm Sep 25 '14 at 09:05