3 layers vs MVC

Question

3 layers vs MVC

Navigation

#1 by (8 votes)

8

3 layers:

DAL (Where is the model and operations with the bank
BLL (Where is the business rule)
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);
}

Would this be a 3-tier design?

Can I consider that in an MVC project, the only difference is the BLL exchange 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?

Can I consider this project as 3 layers?

c# asp.net-mvc

asked by anonymous 22.09.2014 / 01:41

1 answer

How to get all records of a mixed table generated by class inheritance when using EntityFramework 6? How to manage my message flow?

score 8 · Accepted Answer

Would this be a 3-tier design?

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

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

No. It's common to think so, but it goes a little further.

First, you have to see things from the viewpoint 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 relationships of one Model with another, which does not exists in the 3 Layer Model.

In 3 Layers, you need to place validations, relationships, and characteristics of each entity either 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; }
}

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

There are approaches that try to put an extra layer together with Controller , under the assumption that it is not the Controller's responsibility to take care of business rules. This is not true if it is considered as aspect something that it 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 an information to the object and the command to move the object to a data context is part of the harmonization between Models , but it is business rule .

Can I consider this project as 3 layers?

Roughlyspeaking,yes.Whatyoudidwasinserta"Template" layer (which is not a "Template" but a Domain layer, which is another concept). This "Model" layer can be seen by the presentation because it is just an information about what data transfer objects the application will use. It's like a pre-arranged contract between the 3 layers. With no business rules or quirky behavior, you'd just be following the pattern. DDD .