Home/ Questions/Q 4072276
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T16:51:53+00:00

I need to separate ViewModels in my MVC project from my business models (Data

  • 0

I need to separate ViewModels in my MVC project from my business models (Data access layer) which lives in a separate library.

Assume that I have Database Access Layer classes in a separate library. Our primary project (MVC) does know nothing about those classes and they talk to each other through an Interface. It’s easy enough to use IOC and resolve dependency injection using Ninject or something, right?

Now DataAccessLayer contains class named Car with properties Engine and Wheel. In my MVC project (which doesn’t know nothing about DataAccessLayer and its classes) I need to use some Car objects. So I have another Car class (it’s just a pure ViewModel) and it has the same properties – Engine and Wheel (of course in real app there will be some differences between model and viewmodel, for the sake of simplicity let’s ignore that)

IDataAccessLayer Interface has a method called IEnumerable GetAllCars() that returns list of DataAccessLayer.Car objects.
enter image description here
Now I need to create MVCProject.Car collection, iterate through IEnumerable which was returned by GetAllCars(), on every iteration I need to create a new MVCProject.Car object, populate Engine and Wheel properties, and finally add that object to the Collection.

So: everytime I have to create almost the same structures and somehow manage them in different places.

Here is the problem, see? Or it isn’t? I feel like it will end up into big mess if I don’t change that. Don’t repeat yourself principle violation as it is. Tell me please how to make it right. Using I don’t know proxies or prototypes or maybe some other design pattern which I suck anyway. Or some sort of a tool like Ninject (which I only know how to use as IOC container) or Automapper or whatever, which I probably will suck even more than I suck in design patterns.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I also don’t see much of a reason to keep the DAL separate from the MVC layer. In case you’re interested, here is the layout that I’ve used for multiple project and I find it is very usable and flexible.

    DataObjects
    Basic objects with only properties. Also includes enumerations which the DataObjects use.

    DataAccess
    Inherit from DataObjects and add GetByPrimaryKey, GetByForeignKey, GetByUniqueIndex, GetAll, etc., etc. Also contains the Caching layer where you would find StateCache, CountryCache, etc. for quick access to frequently used things. The “GetBy” methods will utilize the caching layer whenever possible.

    Logic
    Static classes, one for each DataObject\Access type. Includes logical work other than simple fetches as detailed in the DataAccess layer.

    Web\Front-end
    UI works with DataAccess and Logic layers to get and update objects as well as call other defined logical APIs.

    I use my own custom-made code generator to generate 98% of this code (except the UI layer).

    • 0