La idea principal detrás de la POO 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 ubican en entidades distintas, el modelo y el controlador respectivamente. En un enfoque de POO equivalente, ¿no deberían colocarse el modelo y el controlador en la misma entidad lógica?
MVC es un ejercicio en Separation of Concerns , una arquitectura de IU. 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 con los datos que contienen, y los datos y el comportamiento siguen siendo encapsulado . En la práctica, un objeto OOP dado puede o no tener una lógica que se corresponda con sus datos, o puede que no tenga ninguna lógica (un Data Transferir objeto , por ejemplo).
En MVC, la lógica de negocios va en el modelo, no en el controlador. El controlador es realmente un intermediario para unir la Vista y el Modelo. Entonces, en el modelo, puedes tener datos y comportamiento en el mismo lugar.
Pero incluso esa disposición no garantiza una fusión estricta de datos / comportamiento. Los objetos que contienen solo datos pueden ser operados por otras clases que solo tienen lógica, y este es un uso perfectamente aceptable de la POO.
Te daré un ejemplo específico. Esto es un poco artificial, pero digamos que tiene un objeto Currency , y ese objeto tiene la capacidad de representarse a sí mismo en cualquier moneda disponible, vinculado al dólar. Así 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 de moneda.
¿Pero qué sucede si quisiera transferir la moneda de una cuenta a otra o depositar alguna moneda? ¿Ese comportamiento también estaría encapsulado en el objeto de 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 (un cajero o cajero automático) para ayudarlo a ingresar ese dinero en su cuenta.
De modo que el comportamiento se encapsularía en un objeto Teller y aceptaría los objetos Currency y Account como entradas, pero no contendría ningún dato en sí mismo, excepto tal vez un poco de estado local (o tal vez un objeto Transaction ) para ayudar a procesar los objetos de entrada.
MVC funciona en un mucho nivel de abstracción más alto que los objetos individuales, y de hecho, cada uno de los tres (modelo, vista y controlador) generalmente consta de muchos objetos que tienen datos y comportamiento .
Que los objetos que encapsulan datos y comportamiento son un buen bloque de construcción 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.
La POO no restringe las interacciones entre los objetos, ya que cada uno tiene sus propios datos y su propio comportamiento.
Piense en una hormiga y una analogía de 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 la OOP guía el diseño de hormigas individuales.
OOP también trata sobre Separación de inquietudes , que es separar diferentes roles / responsabilidades en diferentes objetos.
MVC se separa en estos componentes:
Por lo tanto, estas responsabilidades son claramente distintas y, de hecho, deberían estar separadas en múltiples entidades.
En el patrón Model-View-Controller, los datos y la lógica / algoritmos Se colocan en distintas entidades, el modelo y el controlador. respectivamente.
El modelo y el controlador son dos funciones distintas. Un modelo tiene estado y lógica, y un controlador tiene estado y lógica. El hecho de que se comuniquen no rompe la encapsulación de ninguno de los dos: el controlador no sabe o le importa cómo el modelo almacena sus datos, o lo que hace con los datos cuando el controlador recupera o actualiza alguna parte de ella. El modelo no sabe o le importa lo que hace el controlador con los datos que proporciona el modelo.
Piénsalo de esta manera: si los objetos no pudieran pasar datos de un lado a otro sin romper la encapsulación, ¡realmente solo podrías tener un objeto!
En un enfoque OOP equivalente, el modelo y el controlador no deberían ser colocado 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í hace que sean más comprobables y reutilizables.
MVC es un patrón que describe una forma sensata para que los objetos interactúen; no es en sí misma una meta-clase. En ese sentido, 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 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 deberían estar unificados en un objeto.
La capa del modelo no es meramente datos más de lo que la capa del controlador es meramente lógica.
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 de transformar esa entrada en una forma que el modelo pueda procesar. El framework Java de Struts tiene un buen ejemplo de esto en su modelo Action / Form. El formulario se rellena con la entrada del usuario y luego se pasa a la Acción. La Acción toma esos datos y los utiliza para manipular el modelo.
De la misma manera, la capa de modelo no consiste completamente en datos. Tome un objeto de Usuario, por ejemplo, es posible que necesite un código que obtenga a un usuario de una base de datos, o un código para asociar a 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 lógica de negocios, y ha llevado a muchos a dividir su capa de modelo en varias capas, como las capas de administrador o administrador para la lógica de negocios, 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 de modelos individuales. Funciona a un nivel más alto que eso, es un método para organizar cómo se accede a la aplicación. View es para presentar datos y acciones humanas para manipularlo, Controller es para la traducción entre las acciones del usuario y las distintas vistas, y el Modelo es donde residen los datos comerciales y las razones comerciales por las que existen.
El objetivo de la POO 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 parte de los 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 el cambio de vista siempre que necesite 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 quiere 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 los datos persistentes vinculados a un objeto modelo con los datos de aplicación de las bases de datos con las que interactúa el modelo. Un modelo contiene lógica empresarial 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, configurar o manipular datos o realizar una compra. Estamos hablando de esas banderas cuando discutimos los objetos en términos de encapsulación de un conjunto de métodos y valores o datos persistentes.
Al igual que el objeto modelo mantiene datos para establecer qué reglas de negocios están en juego, un controlador debe, IMO, conservar datos de estado de aplicación más generales pertinentes a cómo debe comportarse la aplicación, como si el usuario inició sesión o no. tener datos de tarjeta de crédito válidos en su lugar. Los métodos modelo determinarían el estado de estas cosas en primer lugar, pero tiene sentido que el controlador mantenga los indicadores pertinentes al flujo general de aplicaciones si no se aplican a la forma en que se ejecuta el negocio o se realizan las transacciones de datos. Una vez que haya determinado que no están conectados, ni siquiera moleste al modelo con las comprobaciones del 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 se ven en la mayoría de los marcos web del lado del servidor. Una vez que se carguen las preferencias de color del usuario, debe ser la vista que mantiene esos datos y se ejecuta en ellos. La carga, la validación y el cambio de la configuración son problemas del modelo, pero solo deberían ser problemas del modelo una vez hasta que se produzcan cambios.
OMI, nada dice que los controladores no pueden ser objetos compuestos con vistas y modelos como objetos agregados internos. Esto realmente tiene sentido si aplica MVC en una escala más pequeña como una fábrica de widgets de UI, ya que el controlador es el lugar ideal para exponer una interfaz a objetos de aplicaciones de nivel más alto al tiempo que entierra los datos y los detalles lógicos de cómo interactúan la Vista y el Modelo. Sin embargo, no tiene sentido para los objetos de aplicaciones monolóticas en los que el controlador es realmente el objeto de nivel más alto.
Como yo 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 principal 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? Así que son más parecidos que cualquier otra cosa.
Creo que MVC es solo la evolución natural de la POO y me atrevo a decirlo; una mejor manera de organizar sus objetos, la separación de preocupaciones y la reutilización del código.
Llego tarde a esta fiesta y, considerando todas las respuestas antes que la mía, admito que no tengo muchas novedades 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 visualizar fácilmente el código orientado a procedimientos en un patrón MVC (que es lo que sentí como si estuvieras insinuando).
Entonces, creo que la verdadera pregunta es; somos más propensos al código de procedimiento cuando usamos el patrón MVC.
(y tal vez solo obtenga algunos votos a la baja?)
No es anti, pero tampoco se requiere OOP para MVC.
Porque los controladores, que generalmente están representados por Classess, no tienen datos. Para lo cual bastarían las funciones puras.
Si va más lejos y separa los datos del comportamiento, por ejemplo, digamos que los modelos solo funcionan con datos de 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 los campos de instancia) - entonces puede decir lo mismo para los modelos.
Yendo más allá, si toma la capa de visualización de una aplicación y la divide de manera similar, terminará con la conclusión de que MVC no tiene nada que ver con la POO, y es completamente posible escribir la implementación de MVC sin ningún problema. Sólo enfoque de procedimiento.
En mi opinión, los OOP tienen el inconveniente de que (los datos y el comportamiento) están moldeados como una sola entidad (Clase), esto muestra más efecto de acoplamiento que cohesión. Mientras que, por otro lado, MVC tiene un modelo que contiene ... (Beans, DAOs, Otras clases de lógica), El controlador que especifica cómo debe viajar el control y las Vistas para determinar cómo deben mostrarse los datos se dan de forma separada. En base a esto, no importa si el proyecto es Demasiado grande para preparar, se puede hacer fácilmente como una entidad separada, aparte de mezclarse a diferencia de los POO. El problema se resuelve en un patrón lógico, al igual que la estrategia de dividir y conquistar, y MVC sigue este ejemplo.
Lea otras preguntas en las etiquetas object-oriented design mvc