¿No es MVC anti OOP?

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?)

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 .

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.