Is ASP.NET MVC slow as compared to traditional approach

I haven't worked much with MVC, however I have worked a lot with MVVM and here's my take on it:

Question, Answer, and User are all data objects. Its OK for them to know of each other, but they should not be aware of anything outside of the data object layer, such as Views, Controllers, ViewModels, etc.

In an ideal world, your View only references the Models. They might know of the Controller, but they shouldn't have to reference it directly. The ViewModel only knows of other Models. The Controller knows about Models and ViewModels. It doesn't care about the View at all, even though it supplies the View with ViewModels or Models.

So your objects end up looking like this:

• M odels come in two varieties: Models and ViewModels.

  • Models are simple data objects that simply exist to hold data, and are generally a reflection of database data. They do not access the database or contain any sort of business logic that is unrelated to them.
  • ViewModels are data objects that contain data that the View needs, not necessarily what the database needs. They can contain Models, although Models should not contain ViewModels.

• C ontrollers contain your business logic. They control the data access calls, creating Models/ViewModels to pass to the View, advanced business logic such as permissions, etc. They basically control the entire code layer.

• V iews are just used to give the users a user-friendly interface. They accept either a ViewModel or Model, and display it in some way that looks nice to the user.

main MVC project, where M of MVC was moved to Data Access Layer

Common misconception. The M of MVC has nothing to do with data, despite the many examples and tutorials that claim so.

M is your ViewModel and should reside in your MVC project. The ViewModels you have in your BLL are actually to be named DataContracts or BusinessModels.

In your controller you have something comparable to this:

Get(id):
    dataContract = _service.Get(id);
    viewModel = Map(dataContract);
    return viewModel

In your service, something like this:

Get(id):
    dataModel = _dataAccess.Get(id);
    dataContract = Map(dataModel);
    return dataContract;

And in the DataAccess, you perform the proper joins according to the object requested. You are however of course free to add custom methods to your DataAccess when required, so your service can call those methods:

GetWithBars():
    dataModels = _repository.Query("select from foos join bars");
    return dataModels;