MVC

Editar 0 14

MVC: Model View Controller

En programacin PHP5 usaremos el patrn de diseo MVC Model View Controller modelo: mysql (lgica de negocio y accesos a base de datos) vista: html (diseadores y maquetadores) controller: php (respuesta a las peticiones del explorador, cargando una vista con los datos obtenidos de un modelo).

El Controlador o o o o Se llama desde el navegador Lee el modelo y escribe en la vista un controller puede tener diferentes VISTAS y diferentes MODELS. En el controlador va la codificacin / programacin del formulario. en el controller pongo include ("formulario.php") en formulario.php quito el action, para que se llame a si mismo Cada archivo que procese un formulario se llamara controler. La accin va a estar dentro del controlador. Encima del controlador ir un switch.... para escoger el tipo de accin.

Vistas o o o o Las dividimos en (habr un layout para cada uno) frontend (parte pblica) backend (para usuarios registrados) website wireframe define las vistas cada vista tiene extensin .phtml Un modelo nunca llama a una vista. Es el controlador el que rellena una vista con los datos del modelo.

Model Aqui est el cdigo de todas las funcionalidades Puede haber infinitas lineas, libreras externas (Zend framework)

http://trucosphp.wikispaces.com/MVC

MVC es un patrn de diseo. NO es una arquitectura. De modo que los actores del patrn (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 aplicacin. Aqu HAY lgica de negocio. Son tus clases "producto", "usuario", "pedido", o lo que sea. Y son clases que tienen la lgica de negocio en ellas. Un "pedido" por ejemplo no slo tiene las propiedades del pedido sino tambin mtodos 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 vlido debe tener al menos 1 producto y debe tener una direccin de entrega. Slo debe saber guardar y recuperar los datos. La Vista es la representacin de un aspecto del modelo. Por ejemplo una Vista puede ser la ficha del producto. Las Vistas estn dentro de la capa de presentacin, 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 presentacin o estn a caballo entre la capa de presentacin y la de negocio. Algunos autores diran que se podra ver ah una capa de "Lgica de presentacin". En realidad lo que ocurre es lo que he dicho antes, que voy a repetir de nuevo: Una cosa es un patrn de diseo y otra cosa es una arquitectura. Son cosas diferentes. Por poner un ejemplo militar: La arquitectura equivaldra a la estrategia general que se establece a alto nivel en la guerra. Un patrn de diseo equivaldra a una maniobra tctica que se realiza en una batalla determinada.

Aviso: No tomarse la comparacin al pi de la letra. Programar no se parece nada a hacer casas. Todas las cosas se pueden ver a ms 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 an ms puedes pensar cosas como poner la caja de ascensores en el centro del edificio, hacer el edificio con un jardn interior o hacer 8 metros de cimientos.

Todo eso tiene que ver con hacer un edificio. Cuanto ms cerca del detalle ests, ms concretas son las soluciones. Cuanto ms lejos, ms 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 "diseo de interiores", por ejemplo. Pero el conjunto de decisiones que tomas en el diseo de interiores o incluso en la albailera o en la instalacin elctrica estn determinados por las decisiones de alto nivel y tambin 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 lnea de cdigo u otra. En un siguiente nivel podramos 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 podra solucionar este aspecto del programa utilizando un Decorator? La arquitectura (hablando de desarrollo de software) estara un nivel ms arriba an. Son decisiones como "usemos n-capas", "montemos una aplicacin web de frontend y comuniquemos a travs de XMLRPC con un backend de servicios", "utilicemos un sistema centralizado de identificacin y permisos de acceso", "separemos la funcionalidad en mdulos 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 deca estn en un nivel de abstraccin ms alto.

Hay autores que plantean el MVC como MMVC, donde hay dos tipos de modelo. El modelo de negocio y el modelo de aplicacin. El modelo de negocio es donde se alojan los objetos del negocio (clientes, productos, facturas...). En cambio, el modelo de aplicacin 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 tecnologa, y ajenas al dominio del problema) por ejemplo lo que es persistencia. Y como bien dijeron antes, estas "separaciones" no son del todo rgidas, simplemente se hacen para simplificar algunas cuestiones de

diseo y hacer sistemas ms "flexibles", por lo que romper un poco esas lineas no esta mal.
__________________

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 aplicacin esta en el modelo bien, si quieres dentro de tu modelo hacer subseparaciones bien tambin. 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 perfeccin), ni los patrones de diseo perfectos, ni ninguna solucin 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.