Question

I was wondering if the solution I make could be done smarter, and well I guess so. My problem is that I got a class libary where I Keep all my methods. Then I got my MVC where I use a model. These two model are the same, but I need to convert those, and its stupid.

In my class libary I use Entity Framework, where I get the self generated classes.

In my MVC Model class I create a class so I can put on regular expression and so.

The problem: when I want to send a method back I often just want to send the object I get in return from my view. Im tired of creating an instance of an object and then do this:

    [HttpPost]
    public ActionResult CreateUser(UserModel user)
    {
        //my class libary / entity framework class for a user
        User efUser = new User();
        efUser.Email = user.Email;
        efUser.Username = user.Username;
        efUser.Password = user.Password;

        UserBLL userBLL = new UserBLL();

        //send the method to classlibary / logic layer
        userBLL.CreateUser(efUser);

        return RedirectToAction("Index");
    }

Answer 1

Here’s something I posted on a similar question! Hope it helps you understand layering your apps in MVC better and also you should probably turn the methods on your BLL to non-static to be able to effectively test your application!

Answer:

From a high-level view, when you think about application architecture i.e. data layer, business logic layer and presentation layer, MVC should only be your presentation layer. I have often seen people make the mistake of thinking that in MVC, models represent their data layer, controllers represent the business logic layer and views represent the presentation layer.

You should always have a separate business logic layer (or services layer) which your MVC controllers access to carry out business logic, and also a separate data access layer (or repositories) which is only accessed by your services/business logic layer to retrieve data out of the database.

In your typical MVC application, you may have multiple view models representing the same data layer object (which typically represents a database table). For example, you may have 2 views for to represent information about a person; one is a summary view and the other is a details view. In your MVC application you will have 2 View Models i.e. PersonSummary and PersonDetail both of which are populated from the same Persons table in the data layer and are returned to your Controller Action when your controller calls methods (e.g. GetPersonSummary() and GetPersonDetails()) on the PersonService class (business logic layer).

Layering your applications in this way will make them far more maintainable and testable than treating your View Models as data models and writing all your business logic in the Controller actions.