Question

I’m working on an MVC application using LINQ-SQL to connect to my SQL Server database.

Currently when fetching data, I’m passing the properties of my LINQ objects over to a Domain Model, which I’m then creating properties of in my View Models.

For example my View Model might have the following properties:

public Models.UserModel user { get; set; }
public List<Models.CountryModel> countries { get; set; }

My Domain Models have exactly the same properties as my LINQ objects, and I copy these properties over like:

Models.UserModel user = new Models.UserModel();
user.Username = User.Username;
user.FirstName = User.FirstName;
user.LastName = User.LastName;

Where user is my Models.UserModel object, and User is my LINQ object mapped from the User database table.

As my Domain Model is exactly the same as my LINQ object, is there any advantage for me transferring this data over to a Domain Model, or would it be okay for me to just use LINQ objects in my View Model such as:

public User user { get; set; }
public List<Country> countries { get; set; }

What are the advantages of using a Domain Model? Is this purely to loosely couple with the database LINQ objects?

---

If there are advantages to using Domain Models, how would be best to structure these within my MVC application?

Should they be split off entirely at the “Models” folder level (for example a sub-folder “DomainModels” and “ViewModels”) or coincide (such as “UserEditViewModel.cs” and “UserDomainModel.cs”).

Answer 1

As my Domain Model is exactly the same as my LINQ object, is there any
advantage for me transferring this data over to a Domain Model, or
would it be okay for me to just use LINQ objects in my View Model such
as:

You could reference domain models in your view models in case they are exactly the same. I don’t see any benefit of duplicating this logic except that in the real world they are never the same. You always have some view specific things such as validation or even display labels. The advantage of having pure view models is that your application is no longer tied to your database structure. You could easily flip/flop data access technologies without modifying the UI part. I find it more maintainable to have this clear separation and always tend to make it in my applications.