Cita:
Iniciado por Punchi =O !
que bien... estoi aprendiendo de a poco ahora a lo que se refieren ^^
es por eso que el profe recomendo utilizar J2EE... bueno, la verdad es que no tengo mucho tiempo como para aprender un nuevo lenguaje y completar la tarea, asi que lamentablemente me voi a tener que ir por lo que mas domino, que seria PHP.
interesantes posts... creo que voi aprendiendo jeje... una consulta para asegurarme plis: la separacion de capas se hace por medio de funciones que separen lo que es el despliegue, procesamiento y llamados a la base de datos?
osea que por ejemplo para el caso de PHP, tendria que crear la pagina HTML de tal manera que cuando inserte una funcion de despliegue de noticias por ejemplo, ocurra que de lo mismo en donde la despliegue ya que no va a afectar la capa de... logica? y cuando quiera cambiar la noticia cambio el codigo de la capa de la esa logica para que asimismo no me influya en nada el despliegue de la noticia en HTML. ¿estoy en lo correcto?.. si es asi.. ¿en donde queda la capa de datos? =S
grax! ^^U
Vamos a olvidarnos un poquito del patrón MVC (aunque te recomendaría utilizarlo siempre y además yo creo que puede ser el de uso más extendido) y nos centramos en las tres capas. Tradicionalmente un diseño en tres capas consta de las que ya se ha hablado: presentación, lógica de negocio y persistencia o almacen de datos. Para que sea realmente un diseño en tres capas tienen que estar totalmente separadas. Cada capa debe ofrecer una serie de servicios (que los puedes ver como una API) a las capas superiores. Por ejemplo, defines que acciones se pueden hacer sobre una noticia. Pongamos que solo tienes una función en tu lógica que es publicarNoticia. Ese servicio debe ofrecerse a la capa de presentación para ser llamado desde la interfaz. Quizás para poder publicar una noticia debes hacer algunas cosas mas que almacenarla en la base de datos y mostrarla. Esa serie de acciones deben ser llamadas desde publicarNoticia pero nunca debería a estar accesibles a la capa de presentación. Es decir tu ofreces una API al exterior que abstrae de como se hacen las cosas en tu lógica de negocio. De esta forma la desacoplas de la presentación. Si el día de mañana quieres cambiar por completo la interfaz no te afectará al resto de la aplicación.
Todo esto se hace utilizando el patrón Fachada. Te recomiendo que lo busques y le eches un vistazo (aun no puedo poner links).
Para el acceso a datos también se puede utilizar el patrón fachada, aunque hay uno específico para abstraer la capa de persistencia que es el patrón DAO (Data Access Object). En plataformas como .NET ya te viene implementado y solo hay que adaptarlo. Si sigues ese patrón correctamente, el día de mañana te podrías dar cuenta de que tu aplicación por ejemplo no almacena una gran cantidad de datos y podrías aliviarla sustituyendo el motor de base de datos por un fichero XML por ejemplo sin que eso afecte para nada al resto de la aplicación. Solo tendrías que programar la forma de acceder al XML, pero tu logica de negocio en ningun momento sabe que forma de almacenamiento estas usando. Ella llama a una función que podría ser guardarNoticia siempre y el DAO se encarga de almacenarla correctamente en una BD o en un fichero, lo que estes utilizando en ese momento.
Un Saludo!!