MVC Pattern, ViewModels, Location of conversion

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;

The Model-View-Controller pattern is a UI pattern that follows a few basic principles:

1. The View is a User Interface, a thin veneer in front of the Controller. The only logic that should be in the View (i.e. "Code-Behind") is that logic which pertains directly to interacting with the user.

2. The Controller is a thin veneer in front of the Model. It acts as a switch-yard, shunting requests from the View to the Model for processing. The only logic that should be in the controller is logic that facilitates this communication.

3. The Model contains everything else about your application, including your Data Access layer (in your case Dapper or Entity Framework Code), your Repository Layer (which includes Entities and CRUD methods), and your Business Logic Layer.

The overall architecture so described looks something like this:

Database --> Data Access Layer --> Repository --> Business Layer --> Controller --> View

The arrows indicate the direction of the dependency knowledge; e.g. the View knows about the Controller, but not vice versa, and so on.

The Business Layer can be thought of as a CRUD/Business Transaction converter. On the left side, it speaks Create, Read, Update and Delete, using entities from the Repository. On the right side, it speaks business operations (things like "Print an Invoice" or "Bill a Customer), using what I would call View Model objects. These View Model objects are what the Controller uses to glue the UI to an underlying data representation.

Note in my example how the Business Layer has been abstracted from the Controller. This allows you to use different controllers with the same Business Layer.