O MVC não é anti OOP?

62

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?

m3th0dman
fonte
11
Por que eles precisariam estar na mesma entidade lógica? Você não declarou por que isso seria vantajoso ou por que a OOP ditaria esse acordo.
Robert Harvey
26
Bem, a lógica de negócios segue o modelo, não o controlador. O controlador é realmente apenas um intermediário para colar a View e o Model. Portanto, no modelo, você tem dados e comportamento no mesmo local.
Robert Harvey
2
O que? Unificar dados e comportamento juntos é exatamente o que é OOP.
1013 Andy
3
OOP é sobre separar implementações de interfaces. As interfaces têm mais a ver com comportamento e as implementações mais com dados (e é por isso que os dados tendem a ser ocultos). Portanto, OOP não é unificar dados e comportamento, mas separá-los.
Kaz
5
De qualquer forma, você não deseja agrupar todos os dados e comportamentos em uma classe. Os programas OOP usam mais de uma classe para criar estruturas de objetos. De qualquer forma, se algo é "anti-OOP", isso pode ser uma coisa boa. OOP não é o objetivo final. OOP francamente é uma merda. É hora de superar o POO.
Kaz

Respostas:

45

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.

Robert Harvey
fonte
E em que entidade / pacote deve Tellerser colocado? De Controlleronde os Teller'smétodos são chamados ou Modelporque faz parte da lógica de negócios?
M3th0dman 11/11/12
Tellerentra no Model, embora possa ser chamado a partir do controlador. Faz parte do domínio comercial.
Robert Harvey
Sempre pensei que o uso do Modelo para regras de negócios faz do MVC um padrão semi-eficaz. Usar o Modelo para adaptadores para o aplicativo real e fazer com que os controladores mediem entre os adaptadores e a exibição é sempre muito mais eficaz para alcançar o SoC.
Yam Marcovic
@YamMarcovic: Não sei o que você quer dizer. O modelo é uma espécie de catch-all; na prática, as regras de negócios geralmente são colocadas em sua própria camada de serviço, mas ainda são consideradas parte do Modelo (você não codificaria regras de negócios específicas em um método de controlador individual, por exemplo). Você está certo de que os controladores são um intermediário.
Robert Harvey
5
Uma coisa que eu acho que a maioria das pessoas está enganando sobre o MVC apenas lendo isso são as suposições excessivamente amplas sobre o que "lógica de negócios" significa. Se você não pode exibir seu modelo e usá-lo com o mínimo ou nenhuma modificação em um aplicativo novo que terá os mesmos objetivos de negócios, mas uma arquitetura muito diferente através de um controlador com lógica de aplicativo completamente diferente, você está fazendo errado IMO. Ainda há valor em separar as visualizações de qualquer combinação de tudo o que você tem, é claro, mas C como uma construção leve me parece um ponto chave de separação.
precisa
73

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.

Michael Borgwardt
fonte
A abordagem orientada a objetos pode ser dimensionada no nível de abstração; veja, por exemplo, a razão por trás do Domain Driven Design, que apareceu porque a arquitetura clássica em camadas não é OOPish, mas sim processual. Isso acontece em um nível mais alto de abstração que o MVC.
M3th0dman 10/10/12
6
@ m3th0dman: Você está falando em generalidades amplas e abrangentes. Que tal discutir detalhes, como como o MVC elimina o pesadelo do código espaguete que é o Winforms ou o Webforms?
10248 Robert Harvey
3
@ m3th0dman: essa é uma caracterização bastante simplista do DDD.
22812 Michael Borgwardt
11
@RobertHarvey Para ter certeza de que você é o contraponto de por que o MVC é bom, porque acaba com o espaguete não está realmente em disputa aqui. Concordo, mas tenho a tendência de ver o MVC implementado também no padrão processual. Então, acho que é uma pergunta relevante a ser feita, ou melhor, talvez a pergunta seja "Com que frequência as pessoas implementam o MVC proceduralmente?"
21712 Jimmy Jimmy -offoff
11
@ Robert Harvey O objetivo da pergunta não é sobre o quão bom ou ruim é o MVC; é sobre o fato de que é baseado ou não nos princípios de OO.
M3th0dman 10/10/12
71

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.

dasblinkenlight
fonte
5
+1: Geralmente não gosto de explicações por analogias, mas essa é brilhante.
Michael Borgwardt 10/10
@ Caleb Este é um ponto excelente, muito obrigado!
dasblinkenlight
19

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.

marco-fiset
fonte
É verdade que o princípio da responsabilidade única é útil para o uso eficaz da OOP, mas acho que é demais dizer que "a OOP também se refere ao Princípio da Responsabilidade Única". Isso parece atrasado.
Caleb
@ Caleb Sim, eu entendo o que você quer dizer. Talvez possa ser reformulado, mas você entendeu.
marco-Fiset
18

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.

Caleb
fonte
Eu espero que o controlador tenha lógica, mas pouco ou nenhum estado. Que tipo de estado você acha que o controlador possui?
Matthew Flynn
11
@MatthewFlynn Para iniciantes, um controlador precisa saber sobre a visualização e o modelo. Além disso, pode depender do tipo específico de MVC que estamos falando, mas em geral um controlador pode manter o estado relacionado a como as informações devem ser exibidas (por exemplo, seleção atual), enquanto o modelo lida com as informações exibidas.
Caleb
11
@MattFenwick É isso que eu quero dizer sobre o 'sabor' ... Exatamente o que você armazena no controlador e o que no modelo é uma questão de gosto e convenção. No Cocoa / Cocoa Touch, é comum manter itens como seleção atual e até preferências do usuário no controlador. O MVC, usado em algumas estruturas da web, pode colocar quase tudo no modelo e muito pouco no controlador. YMMV.
Caleb
4
@MatthewFlynn A maioria concorda com você, mas na IMO, as pessoas consideram a lógica de negócios uma categoria mais ampla do que deveria. O controlador lida com a lógica do aplicativo, que as pessoas geralmente confundem com a lógica comercial. Em uma separação ideal de preocupações, eu deveria poder reutilizar um objeto de modelo em uma arquitetura de aplicativo completamente diferente, atendendo aos mesmos objetivos de negócios sem modificação no objeto de negócios. Tudo o que o novo aplicativo precisa fazer é usar a interface e fazer suas próprias coisas com dados e transações, retornados e processados.
Erik Reppen
11
@MattFenwick: Considere a aplicação multiusuário. Há um ponto óbvio para traçar a linha entre modelo e controlador é que o modelo lida com o estado compartilhado e o controlador com o estado local. A seleção atual é local, por isso vai no controlador.
Jan Hudec
4

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.

Jonathan Weatherhead
fonte
2

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.

superM
fonte
2

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.

Michael K
fonte
2

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.

DJClayworth
fonte
0

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.

Erik Reppen
fonte
0

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.

djm
fonte
Eu diria que o MVC e a Arquitetura Baseada em Componentes são padrões de design que não estão fora do domínio das abordagens OOP, enquanto OOD / OOP é simplesmente um monte de confusão e conflito de escolas de pensamento e malacademia sobre como usar uma programação onipresente na fronteira construir corretamente. Comparar as duas categorias de coisas é como comparar quadrados e a caneta que você usou para desenhar os quadrados.
precisa
-1

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)

aserwin
fonte
-1

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 .

luke1985
fonte
Haha, eu vejo algumas pessoas sofrendo com a ** quando confrontadas com fatos. Muito esforço para criar estruturas próprias com OOP? Não suporto o tempo perdido? As respostas mais simples são as melhores.
luke1985
Não sei por que essa resposta tem votos negativos. Ele está dizendo que eles não são parentes, e não "anti". Parece bastante preciso.
Mwilcox
-3

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.

user123790
fonte
Essa é apenas a sua opinião ou você pode apoiá-la de alguma forma?
Gnat