O MVC não é anti OOP?

A principal idéia por trás da OOP é unificar dados e comportamento em uma única entidade - o objeto. Na programação procedural, existem dados e algoritmos separados modificando os dados.

No padrão Model-View-Controller, os dados e a lógica / algoritmos são colocados em entidades distintas, o modelo e o controlador, respectivamente. Em uma abordagem OOP equivalente, o modelo e o controlador não devem ser colocados na mesma entidade lógica?

O MVC é um exercício em Separation of Concerns , uma arquitetura de interface do usuário. É uma maneira de diminuir a complexidade que pode ocorrer nas interfaces do usuário, pois a apresentação não está separada do conteúdo .

Em teoria, todos os objetos podem ter um comportamento que opera nos dados que eles contêm, e esses dados e comportamento permanecem encapsulados . Na prática, um determinado objeto OOP pode ou não ter lógica que corresponda aos seus dados ou pode não ter nenhuma lógica (um Objeto de Transferência de Dados , 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 colar a View e o Model. Portanto, no modelo, você pode ter dados e comportamento no mesmo local.

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

Vou te dar um exemplo específico. Isso é um pouco artificial, mas digamos que você tenha um Currencyobjeto, e esse objeto tenha 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 da sua carteira não pode ser transferido da sua carteira para a sua conta bancária; você precisa de um ou mais agentes (caixa ou caixa eletrônico) para ajudar a colocar esse dinheiro em sua conta.

Assim que esse comportamento possa ser encapsulado em um Tellerobjeto, e ele aceitaria Currencye Accountobjetos como entradas, mas não iria conter todos os dados em si, exceto, talvez, um pouco de estado local (ou talvez um Transactionobjeto) para ajudar a processar os objetos de entrada.

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

O fato de objetos que encapsulam dados e comportamento serem um bom alicerce 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 fins.

OOP não restringe as interações entre os objetos, cada um com seus próprios dados e seu próprio comportamento.

Pense na analogia de uma formiga e de uma colônia de formigas: o comportamento de uma formiga individual (andar o dia inteiro, trazendo comida) é diferente do comportamento da colônia geral (encontre o local mais desejável, faça mais formigas). O padrão MVC descreve a estrutura social desejada de uma colônia de formigas, enquanto o OOP guia o design de formigas individuais.

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

O MVC se separa nesses componentes:

• Modelo: os dados e sua lógica de negócios
• View: representação dos dados
• Controlador: coordenação entre o modelo e a vista.

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

No padrão Model-View-Controller, os dados e a lógica / algoritmos são colocados em entidades distintas, o modelo e o controlador, respectivamente.

Modelo e controlador são dois papéis distintos. Um modelo possui estado e lógica, e um controlador possui estado e lógica. O fato de eles se comunicarem não quebra o encapsulamento de nenhum dos dois - o controlador não sabe nem se importa como o modelo armazena seus dados ou o que faz com os dados quando o controlador recupera ou atualiza parte dele. O modelo não sabe nem se importa com o que o controlador faz com os dados que o modelo fornece.

Pense desta maneira: se os objetos não pudessem passar dados para frente e para trás sem quebrar o encapsulamento, você poderia realmente ter apenas um objeto!

Em uma abordagem OOP equivalente, o modelo e o controlador não devem ser colocados na mesma entidade lógica?

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

MVC é um padrão que descreve uma maneira sensata de os objetos interagirem; não é ela própria uma meta-classe. Nesse sentido, OO é sobre descrever 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. Os controladores representam o comportamento de todo o aplicativo - o que um usuário pode fazer e o que ele pode ver.

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

A camada do modelo não é meramente dados, assim como 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 visualização e transformar essa entrada em um formulário que o modelo possa processar. A estrutura Java do Struts tem um bom exemplo disso em seu modelo de Ação / Formulário. O formulário é preenchido com a entrada do usuário e depois passado para a ação. A Ação pega esses dados e os utiliza para manipular o modelo.

Da mesma forma, a camada Modelo não consiste inteiramente de dados. Pegue um objeto Usuário, por exemplo - você pode precisar de um código que obtenha um usuário de um banco de dados, ou um código para associar um Usuário a um Pedido ou para validar se o endereço do Usuário está dentro da área de serviços da sua empresa ... você obtém o cenário. Esta não é a lógica do controlador. É a lógica de negócios e levou muitos a dividir sua camada de Modelo em várias camadas, como camadas de Serviço ou Gerente para lógica de negócios, uma camada DAO (Objeto de Acesso ao Banco de Dados) para acesso ao banco de dados e outras.

O MVC não é um método para organizar operações individuais do modelo. Funciona em um nível mais alto que isso - é um método para organizar como o aplicativo é acessado. O View é para apresentar dados e ações humanas para manipulá-lo, o Controller é para conversão entre ações do usuário e as várias visualizações, e o Modelo é onde os dados comerciais e os motivos comerciais para a sua existência residem.

O objetivo do OOP é agrupar dados e funcionalidades que pertencem um ao outro . Um cálculo que se baseia em alguns dados nem sempre pertence a esses dados.

No MVC, a funcionalidade para exibir um dado (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. Facilita a alteração da exibição sempre que você precisa fazer uma apresentação diferente dos mesmos dados: ou quando as características do hardware da tela mudam: ou quando você muda do Windows para o Linux; ou quando você deseja que duas pessoas tenham duas maneiras diferentes de visualizar os mesmos dados.

O MVC não está em conflito com o OOP - 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 de negócios e regras para trabalhar com bancos de dados e realizar transações. Ele pode definir e verificar sinalizadores de estado interno, como se existe uma venda hoje, se o usuário se qualifica para o status VIP e, em seguida, ramifica a lógica de acordo quando chegar a hora de acessar, definir ou manipular dados ou realizar uma compra. É sobre essas bandeiras que falamos quando discutimos objetos em termos de encapsulamento de um conjunto de métodos e valores ou dados persistentes.

Assim como o objeto de modelo mantém dados para estabelecer quais regras de negócios estão em jogo, o IMO deve manter um controlador em dados mais gerais do estado do aplicativo pertinentes à forma como o aplicativo deve se comportar, como se o usuário está logado ou possui crédito válido dados do cartão. Os métodos de modelo determinariam o estado dessas coisas em primeiro lugar, mas faz sentido para o controlador manter sinalizadores pertinentes ao fluxo geral de aplicativos se eles não se aplicarem à maneira como os negócios são executados ou as transações de dados são conduzidas. Depois de determinar que eles não estão conectados, nem incomode o modelo com as verificações de estado do usuário até que fique claro que outra tentativa de login está sendo feita.

Da mesma forma, com um objeto de exibiçã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 mantém esses dados e é executada. Carregar, validar e alterar configurações são todos problemas do modelo, mas devem ser problemas do modelo apenas uma vez até que as alterações ocorram.

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

Como eu entendo; O argumento é arquitetura baseada em componentes vs OOP. E sem entrar na guerra religiosa, acho que ambos estão descrevendo a mesma coisa; apenas olhando para ele de diferentes ângulos.

Por exemplo, o objetivo principal de 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 o MVC é apenas a evolução natural do POO e ouso dizer; uma maneira melhor de organizar seus objetos, separação de preocupações 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 pergunta 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, eu posso visualizar facilmente o código orientado a procedimentos em um padrão MVC (que é o que eu senti como se estivesse implicando).

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

(e talvez eu consiga alguns votos negativos)

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

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

Se você for mais longe e separar os dados do comportamento, por exemplo, digamos que os modelos funcionem apenas nos dados do banco de dados, que são obtidos toda vez que sua função (responsável pela manipulação de dados) é chamada (em vez de armazenar algum tipo de dados na instância campos) - 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-la de maneira semelhante, na verdade terminará com a conclusão de que o MVC não tem nada a ver com o OOP, e é completamente possível escrever a implementação do MVC sem nenhum problema, usando apenas a abordagem processual .

Na minha opinião, as OOPs têm uma desvantagem: como os (dados e comportamento) são moldados como uma entidade (Classe), isso mostra mais efeito de acoplamento do que coesão. Enquanto, por outro lado, o MVC possui um Modelo contendo ... (Beans, DAOs, Outras classes lógicas), Controlador que especifica como o controle deve viajar e Views para determinar como os dados devem ser exibidos são fornecidos de maneira separada. Com base nisso, não importa se o projeto é Grande demais para preparar, pode ser facilmente feito como entidade separada, além de se misturar ao contrário dos OOPs. O problema é resolvido no padrão lógico, assim como a estratégia de dividir e conquistar, e o MVC segue isso no máximo.