¿No es MVC anti OOP?

62

La idea principal detrás de OOP es unificar los datos y el comportamiento en una sola entidad: el objeto. En la programación de procedimientos hay datos y algoritmos por separado que modifican los datos.

En el patrón Modelo-Vista-Controlador, los datos y la lógica / algoritmos se colocan en entidades distintas, el modelo y el controlador, respectivamente. En un enfoque OOP equivalente, ¿no deberían colocarse el modelo y el controlador en la misma entidad lógica?

m3th0dman
fuente
11
¿Por qué tendrían que estar en la misma entidad lógica? No ha declarado por qué eso sería ventajoso, o por qué OOP dictaría este acuerdo.
Robert Harvey
26
Bueno, la lógica de negocios va en el modelo, no en el controlador. El controlador es realmente solo un intermediario para unir la Vista y el Modelo. Entonces, en el modelo, tiene datos y comportamiento en el mismo lugar.
Robert Harvey
2
¿Qué? Unificar datos y comportamiento juntos es exactamente de lo que se trata OOP.
Andy
3
OOP se trata de separar las implementaciones de las interfaces. Las interfaces tienen más que ver con el comportamiento, y las implementaciones más con los datos (por eso los datos tienden a estar ocultos). Entonces OOP no se trata de unificar datos y comportamiento, sino de separarlos.
Kaz
55
De todos modos, no desea agrupar todos los datos y el comportamiento en una clase. Los programas OOP usan más de una clase para crear marcos de objetos. Y de todos modos, si algo es "anti-OOP", eso podría ser algo bueno. OOP no es el final de todo. OOP es una mierda. Es hora de superar la POO.
Kaz

Respuestas:

45

MVC es un ejercicio de Separación de preocupaciones , una arquitectura de interfaz de usuario. Es una forma de acorralar la complejidad que puede ocurrir en las interfaces de usuario debido a que la presentación no se separa del contenido .

En teoría, todos los objetos pueden tener un comportamiento que opera en los datos que contienen, y esos datos y el comportamiento permanecen encapsulados . En la práctica, un objeto OOP dado puede o no tener una lógica que corresponda a sus datos, o puede no tener ninguna lógica (un objeto de transferencia de datos , por ejemplo).

En MVC, la lógica empresarial va en el modelo, no en el controlador. El controlador es realmente solo un intermediario para unir la Vista y el Modelo. Entonces, en el modelo, puede tener datos y comportamiento en el mismo lugar.

Pero incluso ese arreglo no garantiza una fusión estricta de datos / comportamiento. Los objetos que contienen solo datos pueden ser operados por otras clases que contienen solo lógica, y este es un uso perfectamente aceptable de OOP.


Te daré un ejemplo específico. Esto es un poco artificial, pero supongamos que tiene un Currencyobjeto, y ese objeto tiene la capacidad de representarse a sí mismo en cualquier moneda disponible, vinculada al dólar. Entonces tendrías 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; } }

... y ese comportamiento se encapsularía con el objeto Moneda.

Pero, ¿qué sucede si quisiera transferir la moneda de una cuenta a otra o depositar alguna moneda? ¿Ese comportamiento también se encapsularía en el objeto Moneda? No, no lo haría. El dinero en su billetera no puede transferirse de su billetera a su cuenta bancaria; necesita uno o más agentes (cajero o cajero automático) para ayudarlo a ingresar ese dinero en su cuenta.

Por lo que el comportamiento se encapsula en un Tellerobjeto, y que aceptaría Currencyy Accountobjetos como entradas, pero no contendría ningún dato en sí, excepto tal vez un poco de estado local (o tal vez un Transactionobjeto) para ayudar a procesar los objetos de entrada.

Robert Harvey
fuente
¿Y en qué entidad / paquete se debe Tellercolocar? ¿ ControllerDesde dónde Teller'sse llaman los métodos o Modelporque es parte de la lógica empresarial?
m3th0dman
Tellerva en el Model, aunque podría llamarse desde el controlador. Es parte del dominio comercial.
Robert Harvey
Siempre he pensado que usar el Modelo para las reglas de negocios hace que MVC sea un patrón semi-efectivo. Usar el Modelo para adaptadores a la aplicación real y hacer que los controladores medien entre los adaptadores y la vista siempre es mucho más efectivo para lograr SoC.
Yam Marcovic
@YamMarcovic: No estoy seguro de lo que quieres decir. El modelo es una especie de un todo; en la práctica, las reglas de negocios generalmente se colocan en su propia capa de servicio, pero aún se considera parte del Modelo (por ejemplo, no codificaría reglas de negocios específicas dentro de un método de controlador individual). Tienes razón en que los controladores son un intermediario.
Robert Harvey
55
Una cosa que creo que la mayoría de las personas se está equivocando acerca de MVC solo por leerlo es suposiciones demasiado amplias sobre lo que significa "lógica de negocios". Si no puede extraer su modelo y usarlo con una modificación mínima o nula en una aplicación nueva que tendrá los mismos objetivos comerciales pero una arquitectura muy diferente a través de un controlador con una lógica de aplicación completamente diferente, lo está haciendo mal OMI Todavía hay valor en desacoplar vistas de cualquier combinación de todo lo demás que tenga, por supuesto, pero C como una construcción liviana me parece que falta un punto clave de separación.
Erik Reppen
73

MVC funciona a un nivel de abstracción mucho más alto que los objetos individuales, y de hecho cada uno de los tres (modelo, vista y controlador) generalmente constará de muchos objetos que tienen datos y comportamiento.

Que los objetos que encapsulan datos y comportamiento son un buen elemento fundamental para los programas en general no significa que sea el mejor patrón en todos los niveles de abstracción y para todos los propósitos.

Michael Borgwardt
fuente
El enfoque orientado a objetos puede escalar en el nivel de abstracción; vea, por ejemplo, la razón detrás del diseño impulsado por dominio, que apareció porque la arquitectura clásica en capas no es OOPish sino más bien procesal. Esto sucede en un nivel de abstracción más alto que MVC.
m3th0dman
66
@ m3th0dman: Estás hablando en generalidades amplias y amplias. ¿Qué hay de discutir detalles específicos, como cómo MVC elimina la pesadilla del código de espagueti que es Winforms o Webforms?
Robert Harvey
3
@ m3th0dman: esa es una caracterización bastante simplista de DDD.
Michael Borgwardt
1
@RobertHarvey Para estar seguro de que eres un contrapunto de por qué MVC es bueno porque elimina el espagueti no está realmente en competencia aquí. Estoy de acuerdo, pero también tiendo a ver MVC implementado en el patrón de procedimiento. Entonces, creo que es una pregunta relevante, o más bien, tal vez la pregunta es "¿Con qué frecuencia las personas implementan MVC de manera procesal?"
Jimmy Hoffa
1
@Robert Harvey El propósito de la pregunta no es qué tan bueno o malo es MVC; se trata del hecho de que se basa o no en los principios OO.
m3th0dman
71

OOP no restringe las interacciones entre objetos que tienen cada uno sus propios datos y su propio comportamiento.

Piense en una analogía entre una hormiga y una colonia de hormigas: el comportamiento de una hormiga individual (correr todo el día, trayendo comida) es diferente del comportamiento de la colonia en general (encontrar el lugar más deseable, hacer más hormigas). El patrón MVC describe la estructura social deseada de una colonia de hormigas, mientras que OOP guía el diseño de hormigas individuales.

dasblinkenlight
fuente
55
+1: Normalmente no me gustan las explicaciones a través de analogías, pero esta es brillante.
Michael Borgwardt
@Caleb Este es un excelente punto, ¡muchas gracias!
dasblinkenlight
19

OOP también se trata de la separación de preocupaciones , es decir, separar diferentes roles / responsabilidades en diferentes objetos.

MVC se separa en estos componentes:

  • Modelo: los datos y su lógica de negocio.
  • Vista: representación de los datos.
  • Controlador: coordinación entre el modelo y la vista.

Por lo tanto, estas responsabilidades son claramente distintas y, de hecho, deberían separarse en múltiples entidades.

marco-fiset
fuente
Es cierto que el principio de responsabilidad única es útil para usar OOP de manera efectiva, pero creo que es difícil decir que "OOP también se trata del Principio de Responsabilidad Única". Eso parece al revés.
Caleb
@Caleb Sí, entiendo lo que quieres decir. Tal vez podría reformularse, pero entiendes el punto.
marco-fiset
18

En el patrón Modelo-Vista-Controlador, los datos y la lógica / algoritmos se colocan en entidades distintas, el modelo y el controlador, respectivamente.

Modelo y controlador son dos roles distintos. Un modelo tiene tanto estado como lógica, y un controlador tiene tanto estado como lógica. El hecho de que se comuniquen no interrumpe la encapsulación de ninguno de los dos: el controlador no sabe ni le importa cómo el modelo almacena sus datos, o qué hace con los datos cuando el controlador recupera o actualiza alguna parte de ellos. El modelo no sabe ni le importa lo que hace el controlador con los datos que proporciona el modelo.

Piénselo de esta manera: si los objetos no pudieran pasar datos de un lado a otro sin romper la encapsulación, ¡en realidad solo podría tener un objeto!

En un enfoque OOP equivalente, ¿no deberían colocarse el modelo y el controlador en la misma entidad lógica?

MVC es un enfoque OOP, específicamente, es una receta para decidir cómo usar objetos para organizar un programa de manera efectiva. Y no , el modelo y el controlador no deberían ser la misma entidad. Un controlador permite la separación entre modelo y vista. Mantener el modelo y la vista independientes entre sí los hace más comprobables y más reutilizables.

Caleb
fuente
Espero que el controlador tenga lógica pero poco o ningún estado. ¿Qué tipo de estado crees que tiene el controlador?
Matthew Flynn
1
@MatthewFlynn Para empezar, un controlador necesita saber sobre la vista y el modelo. Más allá de eso, puede depender de lo que en particular sabor de MVC que estamos hablando, pero, en general, un controlador puede mantener el estado relacionada con cómo la información se debe mostrar (por ejemplo, la selección actual), mientras que el modelo trata con lo que la información se visualiza.
Caleb
1
@MattFenwick Eso es lo que quiero decir sobre el 'sabor' ... Exactamente lo que almacena en el controlador y lo que en el modelo es una cuestión de gusto y convención. En Cocoa / Cocoa Touch, es común mantener cosas como la selección actual e incluso las preferencias del usuario en el controlador. MVC, como se usa en algunos marcos web, puede incluir casi todo en el modelo y muy poco en el controlador. YMMV.
Caleb
44
@MatthewFlynn Most estará de acuerdo con usted, pero en mi opinión, las personas consideran que la lógica de negocios es una categoría más amplia de lo que se supone que es. El controlador maneja la lógica de la aplicación que las personas a menudo se confunden con la lógica de negocios. En una separación ideal de preocupaciones, debería ser capaz de reutilizar un objeto modelo en una arquitectura de aplicación completamente diferente que sirva a los mismos objetivos comerciales sin modificar el objeto comercial. Todo lo que la nueva aplicación tiene que hacer es usar la interfaz y hacer lo suyo con los datos y las transacciones que se devuelven y procesan.
Erik Reppen
1
@MattFenwick: considere la aplicación multiusuario. Un punto obvio para trazar la línea entre el modelo y el controlador es que el modelo maneja el estado compartido y el controlador el estado local. La selección actual es local, por lo que va en el controlador.
Jan Hudec
4

MVC es un patrón que describe una forma sensata para que los objetos interactúen; no es en sí una metaclase. En ese momento, OO se trata de describir comportamientos y datos de entidades, y cómo interactúan dichas entidades. No se trata de unificar todo el sistema en un solo objeto masivo.

Jonathan Weatherhead
fuente
2

El controlador no representa el comportamiento de un modelo. Los controladores en conjunto representan el comportamiento de toda la aplicación _ lo que un usuario puede hacer y lo que un usuario puede ver.

Es incorrecto ver los controladores y modelos como uno solo. Tienen diferentes propósitos, diferentes semánticas y, por lo tanto, no deben unificarse en un solo objeto.

superM
fuente
2

La capa del modelo no es simplemente datos, como tampoco lo es la capa del controlador.

La capa del controlador tendrá una colección completa de objetos para sus propósitos. Habrá objetos para recibir información de la vista y para transformar esa información en una forma que el modelo pueda procesar. El marco Java Struts tiene un buen ejemplo de esto en su modelo de Acción / Formulario. El formulario se completa con la entrada del usuario y luego se pasa a la acción. La acción toma esos datos y los usa para manipular el modelo.

De la misma manera, la capa Modelo no consiste enteramente en datos. Tome un objeto Usuario, por ejemplo: puede necesitar código que obtenga un usuario de una base de datos, o código para asociar un Usuario con un Pedido, o para validar que la dirección del Usuario se encuentra dentro del área de servicios de su empresa ... imagen. Esta no es la lógica del controlador. Es la lógica empresarial, y ha llevado a muchos a dividir su capa Modelo en varias capas, como las capas de Servicio o Administrador para la lógica empresarial, una capa DAO (Objeto de acceso a la base de datos) para el acceso a la base de datos y otras.

MVC no es un método para organizar operaciones individuales del Modelo. Funciona a un nivel más alto que eso: es un método para organizar cómo se accede a la aplicación. La vista es para presentar datos y acciones humanas para manipularlos, el controlador es para la traducción entre las acciones del usuario y las diversas vistas, y el modelo es donde residen los datos comerciales y las razones comerciales para que existan.

Michael K
fuente
2

El objetivo de OOP es agrupar los datos y la funcionalidad que pertenecen juntos . Un cálculo que se basa en algún dato no siempre pertenece a esos datos.

En MVC, la funcionalidad para mostrar una pieza de datos (vista) se mantiene separada de los datos (modelo). ¿Porqué es eso? Es específicamente para que la lógica de visualización se pueda cambiar sin tener que cambiar los datos subyacentes. Facilita cambiar la vista cada vez que necesita hacer una presentación diferente de los mismos datos: o cuando cambian las características del hardware de la pantalla: o cuando cambia de Windows a Linux; o cuando desea que dos personas tengan dos formas diferentes de ver los mismos datos.

MVC no está en conflicto con OOP: en realidad se deriva de una aplicación correcta de los Principios Orientados a Objetos.

DJClayworth
fuente
0

Creo que está confundiendo datos persistentes vinculados a un objeto modelo con los datos de la aplicación de las bases de datos con las que interactúa el modelo. Un modelo contiene lógica de negocios y reglas para trabajar con bases de datos y realizar transacciones. Puede establecer y verificar indicadores de estado internos, como si hay una venta hoy, si el usuario califica para el estado VIP y luego ramifica la lógica en consecuencia cuando llega el momento de acceder, establecer o manipular datos o realizar una compra. Estamos hablando de esas banderas cuando discutimos objetos en términos de encapsulación de un conjunto de métodos y valores o datos persistentes.

Del mismo modo que el objeto modelo mantiene datos para establecer qué reglas comerciales están en juego, un controlador debe, en mi opinión, conservar los datos de estado de la aplicación más generales pertinentes a cómo debe comportarse la aplicación, como si el usuario ha iniciado sesión o si tiene un crédito válido Datos de la tarjeta en su lugar. Los métodos modelo determinarían el estado de estas cosas en primer lugar, pero tiene sentido que el controlador mantenga indicadores pertinentes al flujo general de la aplicación si no se aplican a cómo se ejecuta el negocio o se realizan las transacciones de datos. Una vez que haya determinado que no han iniciado sesión, ni siquiera moleste al modelo con las comprobaciones de estado del usuario hasta que esté claro que se está realizando otro intento de inicio de sesión.

Del mismo modo, con un objeto de vista adecuado frente a las plantillas HTML más típicas que ve en la mayoría de los marcos web del lado del servidor. Una vez que se cargan las preferencias de color del usuario, debe ser la vista la que mantiene esos datos y los ejecuta. Cargar, validar y cambiar la configuración son todos problemas del modelo, pero solo deberían ser problemas del modelo una vez hasta que ocurran los cambios.

En mi opinión, nada dice que los controladores no pueden ser objetos compuestos con vistas y modelos como objetos agregados internos. En realidad, esto tiene sentido si aplica MVC en una escala más pequeña, como una fábrica de widgets de interfaz de usuario, ya que el controlador es el lugar ideal para exponer una interfaz a objetos de aplicaciones de nivel superior mientras oculta los datos y los detalles lógicos de cómo interactúan la Vista y el Modelo. Sin embargo, realmente no tiene sentido para los objetos de aplicaciones monolóticas donde el controlador es realmente el objeto de más alto nivel.

Erik Reppen
fuente
0

Según lo entiendo; El argumento es la arquitectura basada en componentes vs OOP. Y sin entrar en la guerra religiosa, creo que ambos están describiendo lo mismo; solo mirándolo desde diferentes ángulos.

Por ejemplo, el objetivo de OOP / OOD es hacer que su código sea más modular y reutilizable. ¿Si?

Cuál es exactamente el objetivo de la arquitectura basada en componentes. Entonces son más parecidos que cualquier otra cosa.

Creo que MVC es solo la evolución natural de OOP y me atrevo a decirlo; Una mejor manera de organizar sus objetos, separación de preocupaciones y reutilización de código.

djm
fuente
Diría que el MVC y la arquitectura basada en componentes son patrones de diseño que no están fuera del ámbito de los enfoques de OOP, mientras que OOD / OOP es simplemente un montón de confusión y choque de escuelas de pensamiento y malacademia sobre cómo usar una programación ubicua que limita Construir adecuadamente. Comparar las dos categorías de cosas es como comparar cuadrados y el lápiz que usaste para dibujar los cuadrados.
Erik Reppen
-1

Llego tarde a esta fiesta, y considerando todas las respuestas antes que la mía, admito que no tengo mucho nuevo que ofrecer. Pero me parece que la pregunta no es sobre el patrón en sí, sino sobre la implementación. MVC en sí mismo no se presta a ninguna metodología en particular. De hecho, puedo imaginar fácilmente el código orientado a procedimientos en un patrón MVC (que es lo que sentí que estabas insinuando).

Entonces, creo que la verdadera pregunta es; ¿Somos más propensos al código de procedimiento cuando utilizamos el patrón MVC?

(¿y tal vez solo obtenga algunos votos negativos?)

aserwin
fuente
-1

No es anti, pero tampoco se requiere OOP para MVC.

Porque los controladores, que generalmente están representados por clases, no contienen datos. Para lo cual bastarían las funciones puras.

Si va más allá y separa los datos del comportamiento, por ejemplo, digamos que los modelos funcionan solo en los datos de la base de datos, que obtienen cada vez que se llama a su función (que es responsable de la manipulación de datos) (en lugar de almacenar algún tipo de datos en la instancia campos): entonces puede decir lo mismo para los modelos.

Yendo más allá, si toma la capa de vista de una aplicación y la divide de manera similar, en realidad terminará con la conclusión de que MVC no tiene nada que ver con OOP, y es completamente posible escribir la implementación de MVC sin ningún problema utilizando solo un enfoque de procedimiento .

luke1985
fuente
Jaja, veo que a algunas personas les duele la a ** cuando se enfrentan a hechos. ¿Demasiado esfuerzo haciendo marcos propios con OOP? ¿No soportas el tiempo perdido? Las respuestas más simples son las mejores.
luke1985
No estoy seguro de por qué esta respuesta tiene votos negativos. Él está diciendo que no están relacionados, y que no son "anti". Parece bastante exacto.
mwilcox
-3

En mi opinión, los OOP tienen el inconveniente de que dado que los (datos y comportamiento) se moldean como una entidad (Clase), esto muestra más efecto de acoplamiento que cohesión. Mientras que, por otro lado, MVC tiene un modelo que contiene ... (Beans, DAO, otras clases de lógica), un controlador que especifica cómo debe viajar el control y las vistas para determinar cómo se deben mostrar los datos de forma separada. Con base en esto, no importa si el proyecto es demasiado grande para prepararlo, puede hacerse fácilmente como una entidad separada, además de mezclarse a diferencia de los OOP. El problema se resuelve en un patrón lógico al igual que la estrategia de dividir y conquistar y MVC sigue esto a lo sumo.

usuario123790
fuente
¿Es esta solo tu opinión o puedes respaldarla de alguna manera?
mosquito