Não é MVC anti OOP?

O MVC é um exercício em Separação de dúvidas , uma arquitetura de interface do usuário. É uma forma de corrigir a complexidade que pode ocorrer nas interfaces do usuário devido à apresentação não ser separada do conteúdo .

Em teoria, todos os objetos podem ter comportamentos que operam nos dados que contêm e que os dados e o comportamento permanecem encapsulado . Na prática, um determinado objeto OOP pode ou não ter uma lógica que corresponda aos seus dados, ou pode não ter nenhuma lógica (um Data Transfer Object , por exemplo).

No MVC, a lógica de negócios entra no modelo, não no controlador. O controlador é realmente apenas um intermediário para unir o View e o Model. Assim, no modelo, você pode ter dados e comportamento no mesmo lugar.

Mas mesmo esse arranjo não garante fusão estrita de dados / comportamento. Objetos contendo apenas dados podem ser operados por outras classes contendo apenas lógica, e este é um uso perfeitamente aceitável da OOP.

Vou dar um exemplo específico. Isso é um pouco inventado, mas digamos que você tenha um objeto Currency , e esse objeto tem a capacidade de se representar em qualquer moeda disponível, atrelada ao dólar. Então você teria métodos como:

public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }

... e esse comportamento seria encapsulado com o objeto Currency.

Mas e se eu quisesse transferir a moeda de uma conta para outra ou depositar alguma moeda? Esse comportamento também seria encapsulado no objeto Currency? Não, não seria. O dinheiro na sua carteira não pode ser transferido da sua carteira para a sua conta bancária; você precisa de um ou mais agentes (um caixa ou caixa eletrônico) para ajudar a obter o dinheiro em sua conta.

Assim, esse comportamento seria encapsulado em um objeto Teller e aceitaria Currency e Account objetos como entradas, mas não conteria nenhum dado em si, exceto talvez um pouco do estado local (ou talvez um objeto Transaction ) para ajudar a processar os objetos de entrada.

O MVC trabalha em um muito nível mais alto de abstração do que objetos únicos, e de fato cada um dos três (modelo, visão e controlador) normalmente consiste em muitos objetos que possuem dados e comportamento .

Os objetos que encapsulam dados e comportamento são um bom bloco de construção fundamental para programas em geral, não significa que seja o melhor padrão em todos os níveis de abstração e para todos os propósitos.

A OOP não restringe as interações entre objetos que possuem seus próprios dados e seu próprio comportamento.

OOP é também sobre Separação de preocupações , isto é, separar diferentes funções / responsabilidades em diferentes objetos.

O MVC separa esses componentes:

• Modelo: os dados e sua lógica de negócios
• Visualizar: representação dos dados
• Controller: coordenação entre o modelo e a visão.

Portanto, essas responsabilidades são claramente distintas e devem, de fato, ser separadas em várias entidades.

In the Model-View-Controller pattern the data and the logic/algorithms are placed in distinct entities, the model and the controller respectively.

Modelo e controlador são dois papéis distintos. Um modelo tem estado e lógica, e um controlador tem estado e lógica. O fato de que eles se comunicam não quebra o encapsulamento de nenhum deles - o controlador não sabe ou se importa como o modelo armazena seus dados, ou o que ele faz com os dados quando o controlador recupera ou atualiza alguma parte dele. O modelo não sabe ou não se importa com o que o controlador faz com os dados fornecidos pelo modelo.

Pense desta maneira: se os objetos não pudessem transmitir dados sem interromper o encapsulamento, você realmente só teria um objeto!

In an equivalent OOP approach shouldn't the model and the controller be placed in the same logical entity?

MVC é uma abordagem OOP - especificamente, é uma receita para decidir como usar objetos para organizar um programa de forma eficaz. E no , o modelo e o controlador não devem ser a mesma entidade. Um controlador permite a separação entre modelo e visualização. Manter o modelo e a visualização independentes um do outro torna-os mais testáveis e mais reutilizáveis.

MVC é um padrão que descreve uma maneira sensata de interação dos objetos; não é em si uma meta-classe. Nesse sentido, OO trata da descrição de comportamentos e dados de entidades e como essas entidades interagem. Não se trata de unificar todo o sistema em um objeto massivo.

O controlador não representa o comportamento de um modelo. Controllers juntos representam o comportamento de todo o aplicativo - o que um usuário pode fazer e o que um usuário pode ver.

É errado visualizar controladores e modelos como um só. Eles têm propósitos diferentes, semântica diferente e, portanto, não devem ser unificados em um objeto.

A camada do modelo não é meramente mais do que a camada do controlador é meramente lógica.

A camada do controlador terá uma coleção completa de objetos para seus propósitos. Haverá objetos para receber entrada da exibição e transformar essa entrada em um formulário que o modelo possa processar. O framework Java Struts tem um bom exemplo disso em seu modelo Action / Form. O formulário é preenchido com entrada do usuário e, em seguida, passado para a ação. A ação pega esses dados e os usa para manipular o modelo.

Da mesma forma, a camada Modelo não consiste inteiramente em dados. Tome um objeto Usuário, por exemplo - você pode precisar de um código que obtenha um usuário de um banco de dados ou código para associar um Usuário a um Pedido, ou para validar se o endereço do Usuário está dentro da área que sua empresa presta ... cenário. Isso não é lógica do controlador. É lógica de negócios e levou muitos a dividir sua camada Model em várias camadas, como camadas Service ou Manager para lógica de negócios, uma camada DAO (Database Access Object) para acesso ao banco de dados e outras.

O MVC não é um método para organizar operações individuais do Modelo. Ele funciona em um nível mais alto do que isso - é um método para organizar como o aplicativo é acessado. View é para apresentar dados e ações humanas para manipulá-lo, o Controller é para tradução entre as ações do usuário e as várias visualizações, e o Modelo é onde residem os dados de negócios e as razões comerciais para que ele exista.

O ponto da POO é agrupar os dados e a funcionalidade que pertencem . Um cálculo baseado em alguns dados não pertence sempre a esses dados.

No MVC, a funcionalidade para exibir uma parte dos dados (visualização) é mantida separada dos dados (modelo). Por que é que? É especificamente para que a lógica de exibição possa ser alterada sem a necessidade de alterar os dados subjacentes. Isso facilita a alteração da visualização sempre que você precisar fazer uma apresentação diferente dos mesmos dados: ou quando as características do hardware de exibição mudarem: ou quando você alternar do Windows para o Linux; ou quando você quer que duas pessoas tenham duas maneiras diferentes de ver os mesmos dados.

O MVC não está em conflito com a POO - na verdade, é derivado de uma aplicação correta dos Princípios Orientados a Objetos.

Acredito que você esteja confundindo dados persistentes vinculados a um objeto de modelo com os dados do aplicativo dos bancos de dados com os quais o modelo interage. Um modelo contém lógica e regras de negócios para trabalhar com bancos de dados e conduzir transações. Ele pode definir e verificar sinalizadores de estado interno, como se há uma venda hoje, se o usuário se qualifica para o status VIP e, em seguida, lógica de filial quando chegar o momento de acessar, definir ou manipular dados ou realizar uma compra. São essas bandeiras que estamos falando quando discutimos objetos em termos de encapsulamento de um conjunto de métodos e valores persistentes ou dados.

Assim como o objeto de modelo mantém dados para estabelecer quais regras de negócios estão em jogo, um controlador deve, IMO, manter dados de estado de aplicativo mais gerais pertinentes a como o aplicativo deve se comportar, como se o usuário estivesse logado ou tenha dados de cartão de crédito válidos em vigor. Os métodos do modelo determinariam o estado dessas coisas em primeiro lugar, mas faz sentido que o controlador mantenha os indicadores pertinentes ao fluxo geral do aplicativo, caso eles não se apliquem ao modo como o negócio é executado ou quando as transações de dados são conduzidas. Uma vez que você tenha determinado que não está logado, não se incomode com o modelo com verificações de estado do usuário até que esteja claro que outra tentativa de login está sendo feita.

Da mesma forma, com um objeto de visualização adequado versus os modelos HTML mais comuns que você vê na maioria das estruturas da Web do lado do servidor. Depois que as preferências de cores do usuário são carregadas, deve ser a exibição que se mantém nesses dados e é executada nela. Carregar, validar e alterar as configurações são problemas de modelo, mas só devem ser problemas de modelo uma vez até que as mudanças aconteçam.

IMO, nada diz que os controladores não podem ser objetos compostos com visualizações e modelos como objetos agregados internos. Isso realmente faz sentido se você aplicar MVC em uma escala menor como uma fábrica de widgets de interface do usuário, já que o controlador é o local ideal para expor uma interface a objetos de nível superior enquanto enterra os dados e detalhes lógicos de como a View e Model interagem. Realmente não faz sentido para objetos de aplicativos monolíticos, onde o controlador é realmente o objeto de nível mais alto.

Pelo que entendi; O argumento é arquitetura baseada em componentes versus OOP. E sem entrar na guerra religiosa, acho que ambos estão descrevendo a mesma coisa; apenas olhando de diferentes ângulos.

Por exemplo, o objetivo da OOP / OOD é tornar seu código mais modular e reutilizável. Sim?

Qual é exatamente o objetivo da arquitetura baseada em componentes. Então eles são mais parecidos do que qualquer outra coisa.

Eu acho que MVC é apenas a evolução natural da OOP e ouso dizer isso; uma maneira melhor de organizar seus objetos, separação de interesses e reutilização de código.

Estou atrasado para esta festa, e considerando todas as respostas antes das minhas, admito que não tenho muito a oferecer. Mas parece-me que a questão não é sobre o padrão em si, mas sobre a implementação. O MVC, por si só, não se presta a nenhuma metodologia específica. Na verdade, posso facilmente visualizar o código orientado por procedimentos em um padrão MVC (que é o que eu senti que você estava sugerindo).

Então, acho que a verdadeira questão é; somos mais propensos ao código procedural ao usar o padrão MVC.

(e talvez eu tenha apenas alguns votos para baixo?)

Não anti, mas também OOP não é necessário para o MVC.

Como os controladores, que geralmente são representados por classes, não contêm dados. Para quais funções puras seriam suficientes.

Se você for além e separar os dados do comportamento, por exemplo, digamos que os modelos funcionem somente nos dados do banco de dados, que eles buscam toda vez que sua função (responsável pela manipulação de dados) for chamada (em vez de armazenar algum tipo de dados) nos campos de instância) - então você pode dizer o mesmo para os modelos.

Indo além, se você pegar a camada de visualização de um aplicativo e dividi-lo de maneira similar, você concluirá que o MVC não tem nada a ver com o OOP, e é completamente possível escrever a implementação do MVC sem qualquer dor única abordagem procedural.

Na minha opinião, OOPs tem uma desvantagem de que, uma vez que (dados e comportamento) são moldados como uma entidade (Classe), isso mostra mais efeito de acoplamento do que coesão. Considerando que, por outro lado MVC tem Model contendo ... (Beans, DAOs, Outras classes de lógica), O controlador que especifica como o controle deve percorrer e as exibições para determinar como os dados devem ser mostrados são fornecidos de maneira separada. Com base nisso, não importa se o projeto é grande demais para ser preparado, pode ser facilmente feito como uma entidade separada, diferente de se misturar ao contrário de OOPs. O problema é resolvido em um padrão lógico, assim como a estratégia de dividir e conquistar, e o MVC segue isso na maioria das vezes.