Arquitetura multicamadas: 3-tier e MVC
Gabarito: letra E. A alternativa E está correta ao afirmar que, na arquitetura 3-tier, as regras de negócio são implementadas na Camada de Negócio e, no padrão MVC, essas regras ficam no componente Model. As demais alternativas apresentam equívocos sobre o fluxo de comunicação e a distribuição de responsabilidades nas arquiteturas multicamadas.
Alternativa A — ❌ Incorreta
Afirma que as operações de acesso ao banco de dados são implementadas na camada de Controle do MVC. Na verdade, no MVC o acesso a dados e as regras de negócio pertencem ao Model. O Controlador (Controller) é responsável por receber as entradas do usuário, interpretá-las e acionar o Model e a View. Veja a definição do conteúdo de apoio:
Model-view-controller (Wikipédia):
Modelo é a ponte entre as camadas Visão (View) e Controle (Controller), consiste na parte lógica da aplicação, que gerencia o comportamento dos dados através de regras de negócios, lógica e funções.
Portanto, é o Model quem lida com o banco de dados, não o Controller.
Alternativa B — ❌ Incorreta
Diz que na arquitetura 3-tier o fluxo de comunicação é triangular, permitindo comunicação direta entre todas as camadas. Na arquitetura em três camadas (3-tier), a comunicação é linear e hierárquica: a camada de apresentação (cliente) se comunica apenas com a camada de lógica de negócios, que por sua vez se comunica com a camada de dados. A camada de apresentação não acessa diretamente a camada de dados. O fluxo não é triangular, e sim sequencial.
Alternativa C — ❌ Incorreta
Descreve a arquitetura 2-tier dizendo que o banco de dados e toda a lógica da aplicação (incluindo regras de negócio) são executados no servidor, e apenas os arquivos de apresentação ficam no cliente. Em uma arquitetura cliente-servidor típica de 2 camadas (2-tier), parte da lógica de aplicação (regras de negócio) reside no cliente, não apenas a apresentação. O servidor geralmente gerencia o banco de dados e alguma lógica, mas não toda. A descrição dada se aproxima mais do modelo de terminais burros, não do modelo 2-tier moderno.
Alternativa D — ❌ Incorreta
Alega que, na arquitetura 3-tier, qualquer alteração no banco de dados no servidor exige alteração em todas as máquinas cliente. Isso é o oposto do objetivo do 3-tier: a separação em camadas permite que mudanças na camada de dados (ou na lógica de negócios) sejam feitas sem afetar os clientes, desde que as interfaces entre camadas sejam mantidas. A manutenção centralizada é uma vantagem desse modelo.
Alternativa E — ✅ Correta ⟵ GABARITO
Afirma corretamente que, na arquitetura 3-tier, as regras de negócio são implementadas na Camada de Negócio (business layer), enquanto no padrão MVC essas regras ficam no Model. De fato, o Model é a camada de dados e lógica de negócio no MVC. O texto de apoio confirma:
Model-view-controller (Wikipédia):
Modelo é a ponte entre as camadas Visão (View) e Controle (Controller), consiste na parte lógica da aplicação, que gerencia o comportamento dos dados através de regras de negócios, lógica e funções.
Assim, a alternativa expressa de forma precisa a correspondência entre as camadas do 3-tier e os componentes do MVC.
Gabarito: letra E.