Diferença entre arquitetura de 3 camadas e MVC (Model, View Controller) no ASP.Net

Gostaria muito de saber como a arquitetura de 3 camadas difere do MVC (Model, View Controller) no ASP.Net, pois me parece que a mesma arquitetura se aplica.

Em 3-tier temos User Services Layer, BusinessLayere DataAccessLayer, por outro lado, temos Model, Viewe Controller. Essa parece a mesma arquitetura para mim.

Alguém pode explicar se o que realmente difere da arquitetura dois, como cada camada difere uma da outra?

É como perguntar qual é a diferença entre uma maçã e um caroço de maçã. Essas duas arquiteturas não são substitutas uma da outra. Eu acho que uma visão mais precisa é que a arquitetura de três camadas aumenta o MVC.

A arquitetura MVC

• Modelos: eles representam "coisas" em seu aplicativo. Essa camada ficou um pouco confusa nos últimos anos, como explicarei mais adiante.

• Exibições: A interface do usuário. A coisa com a qual o usuário interage.

• Controladores: o código de programação que responde ao usuário e às alterações na camada do modelo

A arquitetura de três camadas

Com a arquitetura de três camadas, você tem camadas com responsabilidades diferentes.

• Serviços do usuário: (ou "serviços" em geral) Esta camada é mais sobre como coordenar a recuperação e as modificações da camada "modelo". Ações complexas e com várias etapas são executadas aqui

• Camada de negócios: representa as regras de negócios gravadas no código de programação. O que "The Business" deseja é imposto nessa camada.

• Camada de acesso a dados: uma ou mais classes responsáveis ​​por acessar um armazenamento de dados persistente.

A única parte da arquitetura de três camadas que se cruza com o MVC é a "Camada de negócios". Os "Modelos" no MVC e a "Camada de negócios" na arquitetura de três camadas estão tentando alcançar o mesmo objetivo.

O "M" no MVC ficou confuso

A camada "modelo" no MVC se expandiu nos últimos anos. Pelo que vi, existem dois, possivelmente três tipos de modelos:

1. Modelos de domínio: representam as "coisas" com as quais o "The Business" se importa - o domínio de negócios. Essas classes mantêm dados e todos os procedimentos que operam nesses dados para impor regras de negócios. Os modelos de domínio frequentemente estão vinculados a tabelas em um banco de dados. Isso parece se encaixar na "Camada de negócios" da arquitetura de três camadas.

2. Modelos de exibição: são classes usadas para massagear os dados dos modelos de domínio em algo mais agradável à exibição. Isso não se encaixa em nenhum lugar na arquitetura de três camadas, porque os modelos de exibição não implementam lógica de negócios nem fornecem qualquer tipo de serviço ou acesso a dados.

3. Modelos de negócios: em aplicativos complexos, surge a necessidade de dissociar o modelo de domínio da lógica de negócios. Os Modelos de Negócios contêm dados e procedimentos que operam nesses dados para implementar regras de negócios, e os Modelos de Domínio são relegados para "Bolsas de Propriedade" - objetos que apenas mantêm dados, mas não apresentam comportamento. Os modelos de domínio se tornam outra forma de objeto de transferência de dados entre o banco de dados e o aplicativo.

Em nenhum lugar do MVC é mencionado o acesso a dados. Em alguns casos, você verá que o acesso a dados pertence à camada "modelo" do MVC, que, como vimos, não é mais uma camada clara. Realmente vejo a arquitetura de três camadas sendo emparelhada com o MVC para criar um aplicativo inteiro. Um aumenta ou melhora o outro:

• Modelos
  • Modelos de domínio (MVC / 3 camadas)
  • Exibir modelos (MVC)
  • (opcionalmente) Modelos de negócios (MVC / 3 camadas)
• Visualizações (MVC)
• Controladores (MVC)
• Acesso a dados (3 camadas)
• Serviços (3 camadas)

Há alguma interseção, mas elas são amplamente separadas e juntas são usadas para desacoplar e isolar vários componentes de um sistema maior.

Não, eles não são os mesmos.

MVC é um padrão de design para estruturar o código da interface do usuário. Ele poderia ser usado em uma arquitetura de três camadas; nesse caso, o padrão pertenceria à camada de serviços do usuário. Mas também pode ser usado para a interface do usuário em aplicativos que não são de três camadas - por exemplo, uma calculadora sem persistência subjacente e, portanto, sem camada de acesso a dados.

Em uma arquitetura de três camadas com um front-end MVC, os objetos de domínio usados ​​como modelo seriam os objetos da camada de negócios, mas o padrão MVC não especifica realmente que tipo de objetos o modelo é, apenas qual é sua função no padrão. é. Por exemplo, na variante MVVM, os modelos são adaptadores específicos da interface do usuário na parte superior dos objetos de domínio. Nesse caso, até o modelo pertence à camada de serviço do usuário.

Eu sei que haverá toneladas de respostas diferentes, mas eu vou lhe dar minha opinião sobre isso.

É a resposta mais famosa da engenharia de software "Depende".

Essencialmente, se você olhar para ele, além de várias implementações e diferenças teóricas, esses são padrões muito semelhantes com fluxos semelhantes.

Onde o problema depende do aplicativo que você está construindo, um aplicativo da Web simples pode ter apenas uma camada MVC conversando através de um ORM com o DB. Um mais complexo pode ter o MVC manipulando o front-end na Camada de Usuário, com operações mais complexas não expostas ao usuário acontecendo na camada BL, com a camada de dados consistindo em várias fontes.