It would not indicate creating the business methods in the MVC controller. It is very common that you need to expose these methods through a web service, or use the same business rules in a desktop application, for example. The ideal would be to create a specific layer to handle business rules, so your layer can be reused in other projects of your solution. Imagine that you develop within the controller some rule that can be used in other controllers. It would not be very elegant for one controller to access the other.

I believe not to be a class of the model layer because it is not validation of data, but of processes. Is this line of reasoning correct?

It depends. In the question you said the following:

  

I have been reading some questions and answers about the MVC standard and I have seen that the handling of business rules in the Controller layer is correct, for example: Verify that a record already exists in the database before it persists.

I acknowledge that I said something like this, but in the replies in which I stated this the database is managed by the Entity Framework, which would be the Framework that implements a complete repository.

In this case, what the Controller does is invoke the Entity Framework methods only, and not perform the full treatment of a validation cycle.

The role of a Controller is basically to harmonize the data flows between the various components of an application. In the specific case of a validation, this place is the Model .

How can this be done?

• By Attributes;
• Implementing the interface IValidatableObject .

About process validation

When logic is recurring (that is, when it is used in more than one Controller ) the correct approach is using a design pattern called Helper .

What is a Helper ?

Helper is a class, usually static, or an extension method (which is always static, therefore) that contains recurring logic to multiple Controllers . It can be invoked at any time by any Controller , and can use a data context (Entity Framework) or a repository (non-Entity Framework).

In it you can put what you call "process validation," with a complex sequence of steps, without necessarily putting that logic into a Controller .

Enjoying

@Gus said the following in his response:

  

You often need to expose these methods through a web service, or use the same business rules in a desktop application, for example.

This is true, but the idea is that in the MVC6 the programmer writes a Controller for all presentation layers, such as Desktop or Web Service.

There is, in fact, a limitation of an Controller MVC to be almost strictly for a Web project, but this should be simplified in vNext.

(As of this date, vNext has not yet been officially released)

In my company we developed with .NET WebForms and MVC, we separated into 3 layers (3 projects within a solution): the site layout (design and treatment of some parameters), BLL (Business, business rule with the assembly and validation of  CRUD and complex processes of an entity) and the Data Access layer (DAL) that accesses the database, this last layer is called only by the BLL. Advantages: organization and reuse of code, eg I can make a WebService access to my BLL.