3 layers vs MVC

Question

3 layers:

• DAL (Where the classes (model) and bank operations are located
• BLL (Where the business rule is)
• Presentation (Usually the WEB)

An example:

DAL

public class AlunoBanco
{
    public void InserirAluno(Aluno aluno){
        ...
        "INSERT INTO ALUNO (aluno)"
        ....
    }
}

public class Aluno
{
    public string ra {get;set;}
    public string nome {get;set;}
}

BLL

public void InserirAluno(Aluno aluno){
    DAL.InserirAluno(aluno);
}

Presentation

protected void Salvar_Click(object sender, EventArgs e)
{
    var aluno = new Aluno();
    aluno.ra = ra.Text;
    aluno.nome = nome.Text;
    BLL.InserirAluno(aluno);
}

That would be a 3-layer project?

I can consider that in an MVC project, the only difference is the exchange of BLL for a Controller?

MVC

Controller:

[HttpPost]
public ActionResult Create(Aluno aluno)
{
    DAL.InserirAluno(aluno);
    return View();
}

So what’s the difference between MVC and 3 layers?

I can consider this project as 3 layers?

Answer 1

That would be a 3-layer project?

Yes, you defined 3 layers: data, business and presentation.

I can consider that in an MVC project, the only difference is the exchange of BLL for a Controller?

No. It’s common to think that, but it goes a little further.

First of all, we need to see things from the point of view of a Model. A Model is a class that defines not only the data elements, but what values they can receive, how they are validated and the relations of a Model with another, which does not exist in the 3-Layer Model.

In the 3 Layers, you need to put validations, relationships and characteristics of each entity or in the data layer, or in the business layer.

An example of Model:

public class Product
{
    [Key] // Aqui uso um atributo para definir que a propriedade a seguir é chave.
    public int ProductId { get; set; }
    public int CategoryId { get; set; }

    [Required(ErrorMessage = "O Nome é obrigatório.")] // Aqui defini que o campo não pode ser vazio, juntamente com a mensagem de erro que deve ser exibida caso a validação falhe.
    public String Name { get; set; }

    // Aqui defini que um produto pertence a uma, e apenas uma categoria.
    public virtual Category Category { get; set; }

    // Aqui defini que um produto pertence a várias compras.
    public virtual ICollection<Purchase> Purchases { get; set; }
}

Secondly, the responsibility of a Controller is to harmonise and arbitrate relations between Models. It is he who commands the creation, modification, deletion and selection of application data. In addition, it is he who receives the request and decides what should be returned as presentation, such as the data format (HTML, JSON, and so on).

There are approaches that seek to put an extra layer to work together with the Controller, on the grounds that it is not the responsibility of Controller to take care of business rules. This is not true if it is seen as something that he is responsible for doing, in this case, the harmonization of data between Models. In a project that uses Entity Framework, this:

var user = context.Users.Find(userId);
var profile = new Profile { User = user };

context.Profiles.Add(profile);
context.SaveChanges();

That is, the creation of an object, the assignment of information to the object and the command to pass the object to a data context is part of the harmonization between Models, but it’s business rule.

I can consider this project as 3 layers?

Roughly, yes. What you did was insert a layer of "Template" (which is not really "Template", but a layer of Domain, which is another concept). This "Model" layer can be seen by the presentation because it is only information of what the data transfer objects will be like. It is as if it were a pre-established contract between the three layers. If there were no business rules or peculiar behaviors, you would just be following the DDD standard.