Hola, que tal. Muchas gracias por las respuestas, muy interesantes.
Queria agregar algo mas en la explicacion. Por cliente si bien yo lo tome mas puntualmente como una aplicacion winform, para ser bien descriptivo, en realidad se que cliente puede ser cualquier otro tipo de sistema, eso esta claro. Salvatore, muy buena la explicacion que planteas, pero lo que describis es la arquitectura actual de servicio web utilizando .asmx, o WCF. Queda claro que si utilizas web service o WCF, ya deja de ser cliente-servidor. Cuando plantee la consulta lo hice justamente comparando por ejemplo WCF con las implementaciones actuales de REST (que hay varias ADO.NET Data Service, SQL Data Services, etc). No se si estas familiarizado con alguna de estas (aclaro que yo solo tengo un marco teorico, no las utlice en la practica), pero estas exponen directamente la base de datos, permitimiento realizar operaciones de CRUD directo en la base, sin pasar por el servidor de aplicaciones, donde se implemente aunque sea algo de logica. Si se tiene los permiso, se puede desde el cliente, realizar cualquier operacion de CRUD. No se que piensan pero estas nuevas tendencias las veo mas que nada muy bien apuntadas a la implementacion de recuperacion y visualizacion de datos , para grillas, reportes, etc, es mas sino vi mal hasta estan muy unidas a linq por lo que aplicar filtros seria simple. En este punto lo veo genial, quien no habra luchado al respetar todas las capas, teniendo que codificar metodos y metodos del estilo ObtenerTodosEmpleados(), ObtenerEmpleadorPorRango(), ObtenerEmpleadosPorArea(), y asi con todas las entidades y realciones, para que sea simplemente un pasamano de infromacion que se desplegara en un formulario, reporte, grilla, impresion, etc, tarea completamente tediosa. Creo que exponer la db para recuperar y leer datos, pero solo como read only, y ser deplegadas como informacion, esta mas que interesante la propuesta, parece ser muy simple de lograr , y evita de codificar tantas capas y tranductores. Ahora exponer datos, y permitir realizar todas las operaciones me suena un tanto descontrolado. Nota: Salvo que me digas que estos data service sean utilizados desde la capa de aplicacion y no directamente desde el cliente, y la capa de aplicacion utilizando, por ejemplo WCF, exponga la operaciones que se requieren, pero por lo que vi no se si apunta a esto. Por que lo comparare con volver al cliente-servidor, porque cuando uno usa WCF tiene entidades de transporte, y en algun momento hay que transformar a entidades del dominio, requiere agregar cierta logica y manipulacion de datos, y validaciones, calculos, etc. En cambio si se expone directo operacion contra la db, primero se vuelve a una vision Data-centric pura, no tengo nada en contra con esta vision siempre que sea en operaciones de visualizacion o consulta, para operacion sobre datos update, delete, etc, no me cierra mucho, creo que Domain Model es mucho mas rica. Bueno solo queria aportar un poquito mas. Saludos PD, por alguna razon se abrio el thread en dos listas, parece ser que es un tema que tiene mucho en comun con las dos, tanto arquitectura, como patrones. --- El mié 17-dic-08, csalvat...@siprod.net <csalvat...@siprod.net> escribió: De: csalvat...@siprod.net <csalvat...@siprod.net> Asunto: [arquitectura] Re: Fwd: [patrones] Desarrollo n capas, morira en el futuro ? Para: ltuttini_lis...@yahoo.com.ar Cc: patrones@mug.org.ar Fecha: miércoles, 17 de diciembre de 2008, 5:39 pm Leandro, Me parece que estás equivocando el concepto de "Cliente" en este contexto. Aquí cliente es cualquier sistema que consuma esta información. Esto bien puede ser un webservice ubicado en la capa de lógica de negocios de otro sistema. Supongamos que el correo publicara un webservice que recibiera como parámetro el código postal y devolviera el nombre de la localidad correspondiente. En lugar de guardar este último dato en tu repositorio, vos podrías guardar la base de datos sólo el código y ser "cliente" del webservice del correo. Eso no significaría que tu sistema no estuviera dividido en su capa de presentación, capa de lógica de negocios y capa de acceso a datos y el motor de base de datos. Tampoco significa que a su vez tu aplicación no sea más que un webservice que vende algún tipo de información y que siendo "cliente" de ese webservice del correo, no tenga a su vez sus propios clientes. En este caso "cliente" no es lo mismo a lo que uno se refiere cuando habla de una arquitectura cliente-servidor. Tampoco "cliente" implica interfaz de usuario ni capa de presentación. No por el hecho de que tu sistema sea cliente de un servicio que publica datos (gratuito o no), necesariamente va a dejar de tener su propia capa de negocios (multicapa) ni eso implica que puedan o no las distintas capas estar contenidas en componentes que se hospedan en un mismo o distintos servidores (arquitectura multinivel) o que tus capas estén obligadas a estar -o no- en una misma dll o ejecutable. C.S. De: patrones@mug.org.ar [mailto:patro...@mug.org.ar] En nombre de Leandro Tuttini Enviado el: Miércoles, 17 de Diciembre de 2008 12:37 p.m. Para: patrones List Member Asunto: [patrones] Desarrollo n capas, morira en el futuro ? Hola que tal. Queria realizar un planteo que me esta rondando ultimamente la cabeza a ver si les pasa lo mismo. Ultimanente estoy yendo a charlas, disfrutando de videos y articulos, y note un cambio en muchos frameworks que apuntan a exponer datos como servicios. Entre ellos paso a mencionar: ADO.NET Data Service http://msdn.microsoft.com/en-us/library/cc907912.aspx REST http://es.wikipedia.org/wiki/REST http://www.xml.com/pub/a/2004/12/01/restful-web.html SQL Data Services http://msdn.microsoft.com/en-us/library/cc512404.aspx EntityBag (para Entity Framework) http://code.msdn.microsoft.com/entitybag/ O sea salvo que este entendiendo algo mal, todo estos apuntan a exponer datos y ser consumidos desde el cliente, o desde alguna cada especifica pero en el cliente. No me refiero directo en el winform, por ahi en algun assembly especifico, pero instalado en cada terminal. Si esto es asi, eehh no se vuelve a las dos capas, (o al cliente servidor), solo que ahora se realiza por un protocolo estandar como es el http. Donde quedaron, si es como lo pienso, los patrones que dividen en capas, que hace unos años atras vi explicados en tantas charlas ? Ojo entiendo que el arquitecto debe decidir como diseñar las aplicaciones y por ahi no siempre encuadre el uso de estas tecnologias con los requerimientos, pero mas alla de eso, noto como que estan saliendo patrones que hasta hace unos año atras, por la forma como se pensaba, no era nada aconsejable de aplicar. Es mas recuerdo muy claro como con WCF, se deben realizar los proxy y la separacion entre los objetos de dominio, y los de transporte (los famosos DTO). Nota: se que muchas veces para ahorrar tiempo se usan en el cliente los objetos de transporte, aunque era recomendado realizar otra traduccion en este punto. Quien quiera una buena separacion en capas de seguro tuvo que luchar con la codificacion de miles de translators para mapear objetos DTO con los del dominio. Puede ser que estos nuevos frameworks que estan surgiendo sean producto de esto justamente, el de reducir tiempos de desarrollo, para hacer aplicaciones mas funcionales en menos sprint. O tengo otra teoria, que estos frameworks esten apuntados al consumo puramente de datos, o sea para reportes, grillas, etc, y no a la toda a aplicacion. Igualmente esto me confunde un poco ya que segun vi desde implementaciones REST, se pueden realizar operaciones de CRUD. Que piensan de esto que planteo? sera que Martin Fowler, y GOF, deberan rediseñarse dentro de poco algunos de sus patrones ams famosos? Saludos Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer.yahoo.com/cocina/ Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.17/1847 - Release Date: 13/12/2008 04:56 p.m. Yahoo! Cocina Recetas prácticas y comida saludable http://ar.mujer.yahoo.com/cocina/
