Patron de diseño MVC

[Millertaker]

Hola, mas que una pregunta es uan confirmacion, cuando hablamos de MVC (Modelo - vista - controlador) se habla de:

Modelo : Capa de acceso a datos
Vista: Capa de presentación
Controlador: Capa de logica de negocio

[pateketrueke]

exacto!!!

http://es.wikipedia.org/wiki/Modelo_Vista_Controlador

[Lino-kun]

Como dice pateketrueke exacto.

Por si te sirve de algo es una metodología de programación, existen framework que la utilizan por ejemplo Struts de la fundación apache y a mi opinión es el mejor framework que implementa esta metodología.
Si alguna vez necesitas ayuda con esta metodología o si te interesa la programación son struts contáctame. Saludos.

[zsamer]

Iniciado por Lino-kun

Como dice pateketrueke exacto.

Por si te sirve de algo es una metodología de programación, existen framework que la utilizan por ejemplo Struts de la fundación apache y a mi opinión es el mejor framework que implementa esta metodología.
Si alguna vez necesitas ayuda con esta metodología o si te interesa la programación son struts contáctame. Saludos.

En java es mejor Spring según mi punto de vista, tiene una mejor implementación MVC basado en intefaces.

En PHP está Zend Framwork o symfony, aunque me quedo con el de zend.

[venkman]

Realmente NO es eso. MVC es un patrón de diseño. NO es una arquitectura. De modo que los actores del patrón (M, V y C) no corresponden con "capas" de la arquitectura. Son dos cosas radicalmente diferentes.


Modelo: Aquí es donde está el modelo de tu aplicación. Aquí HAY lógica de negocio. Son tus clases "producto", "usuario", "pedido", o lo que sea. Y son clases que tienen la lógica de negocio en ellas. Un "pedido" por ejemplo no sólo tiene las propiedades del pedido sino también métodos que modifican o manejan ese pedido, lo validan, lo marcan como pagado, etc.
El modelo, normalmente, está dentro de la capa de negocio.
La capa de datos únicamente debe implicarse en el acceso a datos. No debe ocuparse de saber que para que un pedido sea válido debe tener al menos 1 producto y debe tener una dirección de entrega. Sólo debe saber guardar y recuperar los datos.

La Vista es la representación de un aspecto del modelo. Por ejemplo una Vista puede ser la ficha del producto.
Las Vistas están dentro de la capa de presentación, pero no son la capa.

Los Controladores reciben las acciones del usuario y las transmiten al Modelo. Los Controladores generalmente forman parte de la capa de presentación o están a caballo entre la capa de presentación y la de negocio. Algunos autores dirían que se podría ver ahí una capa de "Lógica de presentación". En realidad lo que ocurre es lo que he dicho antes, que voy a repetir de nuevo:

Una cosa es un patrón de diseño y otra cosa es una arquitectura. Son cosas diferentes.

Por poner un ejemplo militar: La arquitectura equivaldría a la estrategia general que se establece a alto nivel en la guerra. Un patrón de diseño equivaldría a una maniobra táctica que se realiza en una batalla determinada.

[enriqueplace]

Muy buena explicación, creo que nos has tapado la boca a más de uno

En su momento he hablado con colegas con más conocimientos del tema de diseño (muchos del mundo Java) y la explicación no fue tan clara como la que tú nos estás ofreciendo, y razonando, tiene mucho sentido.

Pero para facilitar explicaciones de como trabajar con un MVC sale fácilmente la analogía de las 3 capas = MVC, tema que nunca me había dejado muy conforme.

Buen aporte

[venkman]

También el problema es que hay una serie de frameworks que se presentan como desarrollados alrededor del patrón MVC y algunos no lo explican bien y confunden eso con una arquitectura.

Un patrón es algo que se aplica a un problema más concreto, más preciso que una arquitectura completa.

[GatorV]

Es por eso que siempre he dicho que un Framework debe de ser aislado y no estar atado a un cierto patrón de diseño, por eso llamo a mi "framework" un Toolbox, ya que se me hace más acertado, a pesar de usar un patrón MVC para cuando programo.

Saludos.

[Millertaker]

Iniciado por venkman

Realmente NO es eso. MVC es un patrón de diseño. NO es una arquitectura. De modo que los actores del patrón (M, V y C) no corresponden con "capas" de la arquitectura. Son dos cosas radicalmente diferentes.


Modelo: Aquí es donde está el modelo de tu aplicación. Aquí HAY lógica de negocio. Son tus clases "producto", "usuario", "pedido", o lo que sea. Y son clases que tienen la lógica de negocio en ellas. Un "pedido" por ejemplo no sólo tiene las propiedades del pedido sino también métodos que modifican o manejan ese pedido, lo validan, lo marcan como pagado, etc.
El modelo, normalmente, está dentro de la capa de negocio.
La capa de datos únicamente debe implicarse en el acceso a datos. No debe ocuparse de saber que para que un pedido sea válido debe tener al menos 1 producto y debe tener una dirección de entrega. Sólo debe saber guardar y recuperar los datos.

La Vista es la representación de un aspecto del modelo. Por ejemplo una Vista puede ser la ficha del producto.
Las Vistas están dentro de la capa de presentación, pero no son la capa.

Los Controladores reciben las acciones del usuario y las transmiten al Modelo. Los Controladores generalmente forman parte de la capa de presentación o están a caballo entre la capa de presentación y la de negocio. Algunos autores dirían que se podría ver ahí una capa de "Lógica de presentación". En realidad lo que ocurre es lo que he dicho antes, que voy a repetir de nuevo:

Una cosa es un patrón de diseño y otra cosa es una arquitectura. Son cosas diferentes.

Por poner un ejemplo militar: La arquitectura equivaldría a la estrategia general que se establece a alto nivel en la guerra. Un patrón de diseño equivaldría a una maniobra táctica que se realiza en una batalla determinada.

Hola pues la verdad entonces me pregunto existen "patrones" para una arquitectura o algo en que fundamentarse para arrancar a establecer una arquitectura para una aplicacion?

Y otra pregunta, Estos Frameworks implementan arquitecturas o patrones dentro de su estructura, eso hablando de Symfony, .NET Framework, Spring para java, etc.

[GatorV]

No existen patrones para una arquitectura, más bien una arquitectura es un conjunto de herramientas para proveer soluciones.

Y sí, muchas arquitecturas hacen uso de patrones para hacer sus herramientas.

Saludos.

[venkman]

Aviso: No tomarse la comparación al pié de la letra. Programar no se parece nada a hacer casas.


Todas las cosas se pueden ver a más o menos distancia. Un edificio, por ejemplo, puedes acercarte mucho y fijarte en detalles como ¿Qué mezcla de cemento debo usar? o ¿Pongo aquí un tubo de 2 pulgadas o de 3? Puedes alejarte un poquito y pensar en detalles como vamos a hacer cocinas americanas en todos los apartamentos o evitemos usar pasillos. Si te alejas aún más puedes pensar cosas como poner la caja de ascensores en el centro del edificio, hacer el edificio con un jardín interior o hacer 8 metros de cimientos.

Todo eso tiene que ver con hacer un edificio. Cuanto más cerca del detalle estás, más concretas son las soluciones. Cuanto más lejos, más abstractas. A cada nivel de detalle le puedes dar diferentes nombres. Aunque todo es arquitectura, el concepto de tener cocina americana o cocina independiente se puede considerar "diseño de interiores", por ejemplo. Pero el conjunto de decisiones que tomas en el diseño de interiores o incluso en la albañilería o en la instalación eléctrica están determinados por las decisiones de alto nivel y también forman parte de la arquitectura.


En el desarrollo de software es parecido. En un nivel muy cercano, tomamos decisiones muy concretas que se reflejan de forma muy directa sobre una línea de código u otra. En un siguiente nivel podríamos encontrar los patrones, que se ven como "soluciones de arquitectura local" es como usar pasillos o no. ¿Esta clase debe ser un Singleton o no? ¿Se podría solucionar este aspecto del programa utilizando un Decorator?
La arquitectura (hablando de desarrollo de software) estaría un nivel más arriba aún. Son decisiones como "usemos n-capas", "montemos una aplicación web de frontend y comuniquemos a través de XMLRPC con un backend de servicios", "utilicemos un sistema centralizado de identificación y permisos de acceso", "separemos la funcionalidad en módulos independientes"...


¿Existen "patrones" para arquitectura? - preguntas -. como ha dicho GatorV no. No existen tal como entendemos la palabra patrones en este contexto. Lo que sí existen son esquemas, recomendaciones, estructuras conocidas. Pero como decía están en un nivel de abstracción más alto.

[GatorV]

Totalmente de acuerdo contigo venkman, me refería a que si muchas arquitecturas usan patrones por decir la mayoría usa Singleton para su clase de acceso a datos, aunque están libres para que el programador sea el que decida que solución mas concreta al problema usar.

Saludos.

[venkman]

Por si acaso: No pretendía corregirte nada, GatorV, sólo complementar lo que decías.

De acuerdo con esa aportación tuya.

[GatorV]

Me agrada que estemos de acuerdo , la verdad la teoría de las arquitecturas es muy interesante.

Saludos.

[Millertaker]

Exelente
Muchas Gracias!!!

[theharder]

No sé si sea tarde para revivir este foro, pero ya que veo que Venkman y GatorV son expertos en el tema, quisiera que me aclararan algo:

En el modelo esta todo lo relacionado con la lógica del negocio y el acceso a datos, no debería haber ahi como una subespecie de division ahi? ya que como vos explicas en un post anterior, las clases encargadas de acceder a los datos no les debe importar ni es responsabilidad de ellas saber por ejemplo que un pedido es valido si tiene al menos un producto solicitado.

Podría haber como composiciones o grandes patrones formados por otro patrones, como por ejemplo (no sé si se pueda hacer esto o exista) una unión entre el patrón MVC y el DAO?

[GatorV]

El que uses el patrón MVC no te restringe de usar otros patrones, la idea de MVC solamente es separar las capas de tu aplicación para que sea más facil el mantenerla.

Saludos.

[guille_el3]

Hay autores que plantean el MVC como MMVC, donde hay dos tipos de modelo. El modelo de negocio y el modelo de aplicación.
El modelo de negocio es donde se alojan los objetos del negocio (clientes, productos, facturas...).
En cambio, el modelo de aplicación es donde se alojan esas otras cosas que no son ni vista, ni controlador, ni modelo de negocio, (estamos hablando de cosas inherentes a la tecnología, y ajenas al dominio del problema) por ejemplo lo que es persistencia.

Y como bien dijeron antes, estas "separaciones" no son del todo rígidas, simplemente se hacen para simplificar algunas cuestiones de diseño y hacer sistemas más "flexibles", por lo que romper un poco esas lineas no esta mal.

[theharder]

.....excelente aporte, yo ya llevaba rato echandole cabeza a la idea que adentro del modelo debería haber una parte que se dedicara a manejar la persistencia de los datos ya sea en una base de datos, ficheros, XMLs.....etc y otra donde esta contenida la lógica del negocio, donde esta última no conociera nada del método de persistencia de datos; como quien dice fuera invisible para ella.

[Lord Kazuky]

Según entendi, en el "Modelo" puede estar tanto la lógica del negocio como esa parte de la persistencia, depende de la "Arquitectura" que se maneje si se decide tener esto en capas separadas o no, y esta elección depende del problema en particular a resolver.

[guille_el3]

Bleh, usar MVC o no usar MVC, o tener una arquitectura en capas o no depende de muuuuuchas pero muuuuchas cosas.
Y la primera es que se justifique.

Muchos autores exponen sus patrones/arquitecturas y dicen que es la mejor... Unos separan en 2, 3 5 8 capas, que sean 25, no me importa... Que persistencia, que haya otra entre la de dominio y la de persistencia, son discusiones quizas interesantes pero que probablemente nunca tengan un fin, solo gente infeliz.

La separacion en capas es solo conceptual, al final terminan siendo solo un monton de archivos tirados por ahi (y con suerte en carpetas distintas y bien administrados =P).
No tiene sentido hablar de "en la capa de modelo va la parte de persistencia segun MVC" porque MVC es una estructura mental para organizar un problema y buscar una solucion mas flexible y robusta quizas...

Repito, salirse de MVC no está mal, tener interpretaciones distintas tampoco. Si te resulta útil ver que toda tu aplicación esta en el modelo bien, si quieres dentro de tu modelo hacer subseparaciones bien también.

Y lo digo porque normalmente las soluciones "de libro" no calzan en la vida real, y no calzan ni las arquitecturas "perfectas" (porque no existe la perfección), ni los patrones de diseño perfectos, ni ninguna solución perfecta!

¿Quien me va a prohibir hacer un strategy statefull porque en el libro de gof recomienda que sean stateless para que sean singleton? NADIEEEE =P
Si me conviene y convence hacerlos statefull adelante.

Eso, :)

[enriqueplace]

¿Guille, que te fumaste?

[guille_el3]

Jajajaja, solo quería romper un poco con esos pensamientos estructurados y poco sanos , además me gusta discutir

[lisandro Arg]

OFFTOPIC !

Iniciado por guille_el3

Bleh, usar MVC o no usar MVC, o tener una arquitectura en capas o no depende de muuuuuchas pero muuuuchas cosas.
Y la primera es que se justifique.

Muchos autores exponen sus patrones/arquitecturas y dicen que es la mejor... Unos separan en 2, 3 5 8 capas, que sean 25, no me importa... Que persistencia, que haya otra entre la de dominio y la de persistencia, son discusiones quizas interesantes pero que probablemente nunca tengan un fin, solo gente infeliz.

La separacion en capas es solo conceptual, al final terminan siendo solo un monton de archivos tirados por ahi (y con suerte en carpetas distintas y bien administrados =P).
No tiene sentido hablar de "en la capa de modelo va la parte de persistencia segun MVC" porque MVC es una estructura mental para organizar un problema y buscar una solucion mas flexible y robusta quizas...

Repito, salirse de MVC no está mal, tener interpretaciones distintas tampoco. Si te resulta útil ver que toda tu aplicación esta en el modelo bien, si quieres dentro de tu modelo hacer subseparaciones bien también.

Y lo digo porque normalmente las soluciones "de libro" no calzan en la vida real, y no calzan ni las arquitecturas "perfectas" (porque no existe la perfección), ni los patrones de diseño perfectos, ni ninguna solución perfecta!

¿Quien me va a prohibir hacer un strategy statefull porque en el libro de gof recomienda que sean stateless para que sean singleton? NADIEEEE =P
Si me conviene y convence hacerlos statefull adelante.

Eso, :)

genial jaja nunca me rei tanto en forosdelweb, "al final terminan siendo solo un monton de archivos tirados por ahi (y con suerte en carpetas distintas" jaja genial genial, me mató. Me hizo acordar a Calamaro cuando le preguntaban que le parecia el recital y respondio: "y... es una situacion de estupefacientes".

Perdon por el offtopic pero no aguanté

[sofiadiana]

Iniciado por venkman

Realmente NO es eso. MVC es un patrón de diseño. NO es una arquitectura. De modo que los actores del patrón (M, V y C) no corresponden con "capas" de la arquitectura. Son dos cosas radicalmente diferentes.


Modelo: Aquí es donde está el modelo de tu aplicación. Aquí HAY lógica de negocio. Son tus clases "producto", "usuario", "pedido", o lo que sea. Y son clases que tienen la lógica de negocio en ellas. Un "pedido" por ejemplo no sólo tiene las propiedades del pedido sino también métodos que modifican o manejan ese pedido, lo validan, lo marcan como pagado, etc.
El modelo, normalmente, está dentro de la capa de negocio.
La capa de datos únicamente debe implicarse en el acceso a datos. No debe ocuparse de saber que para que un pedido sea válido debe tener al menos 1 producto y debe tener una dirección de entrega. Sólo debe saber guardar y recuperar los datos.

La Vista es la representación de un aspecto del modelo. Por ejemplo una Vista puede ser la ficha del producto.
Las Vistas están dentro de la capa de presentación, pero no son la capa.

Los Controladores reciben las acciones del usuario y las transmiten al Modelo. Los Controladores generalmente forman parte de la capa de presentación o están a caballo entre la capa de presentación y la de negocio. Algunos autores dirían que se podría ver ahí una capa de "Lógica de presentación". En realidad lo que ocurre es lo que he dicho antes, que voy a repetir de nuevo:

Una cosa es un patrón de diseño y otra cosa es una arquitectura. Son cosas diferentes.

Por poner un ejemplo militar: La arquitectura equivaldría a la estrategia general que se establece a alto nivel en la guerra. Un patrón de diseño equivaldría a una maniobra táctica que se realiza en una batalla determinada.

hola podrias explicarme entonces que arquitectura se emplea para aquellas aplicaciones web que son desarrolladas en mvc porfis.


Pregunta con tema en: http://www.forosdelweb.com/f50/patron-mvc-php-716641/