Excelente este es el punto a donde queria llegar, lo que explicas es exacto lo que pienso.
Ahora bien, basandome en los puntos A y B que planteas, la pregunta es: REST y sus implementaciones a donde apuntan ? mas alla de demostrar que se puede exponer la db facilmente. De que sirve exponer los datos, y podes realizar todas las operaciones con ellos, si sabemos que utilizarlos desde el cliente generar una arquitectura pobre, que desemboca en los puntos A y B. O sea, sirve para saber que podemos hacerlo, y nada mas, o hay algo que no estoy viendo. Aclaro, me refiero a utilizar REST (y sus implementaciones) desde el cliente (winform, webform u otros sistemas). Si haria una excepcion si se tratara de partes de la aplicacion en donde solo se necesite visualizar datos, pero siempre read only (reportes, grillas), creo que en este punto especifico me gusta bastante, pero solo para este. De esta forma se evistaria (como mencione en en mail anterio) los interminables metodos pasa mano y las tranformaciones de DataContracts solo para cargar una grilla. No lo habia pensado pero para ABM muy simples, del tipo pais, provincias, eehh como que podria ser una alternativa agil. Pero solo para estos caso en particular. Queria realizar una anotacion adicional, por ahi me derive a REST por se mas claro, pero esto mismo queria haberlo planteado con por ejemplo EntityBag. La verdad no lo use y por ahi comente algo incorrecto, lo que se de este lo comento Daniel Laco en la ultima presentacion de Entity Framework que se expuso en Microsoft. O sea puntando ahora a este ultimo, lo que hace es reconstruir el Storage Manager, de una entidad de dominio enviada al cliente en un ambiente desconectado. Esto no esta relacionado con REST, pero tiene algo que ver, utilizar EntityBag, se que hace la vida mas simple, pero no rompe un poco la arquitectura, donde queda el clasico DTO, y el concepto de aplanar los objetos antes en enviarlos al cliente. Ojo me refiero a un ambiente en donde exista un aplication server y en donde el cliente ya sea winform o webform consuma los datos desde otro appdomain, si esta en el mismo ahi ya no hay transporte, asi que da lo mismo. A donde quiero apuntar, a que ultimamente estan surgiendo tecnologias que me da la sensacion, que es como que atentan contra las arquitecturas clasicas, que tiempo atras se explicaron en tantas charlas, y por ahi a un arquitecto sin tanta experiencia pueden confundir y adoptarlas incorrectamente, mas que nada porque estas venden mucha agilidad en el desarrollo y resultados rapidos, pero para nada tiene en cuenta el desacoplamiento y cohesion. Es correcto lo que planteo, por ahi me extendi mucho, pero creo que es un tema de arquitectura interesante de discutir. Saludos --- El jue 18-dic-08, csalvat...@siprod.net <csalvat...@siprod.net> escribió: De: csalvat...@siprod.net <csalvat...@siprod.net> Asunto: [arquitectura] FW: Re: [patrones] Fwd: Desarrollo n capas, morira en el futuro ? Para: ltuttini_lis...@yahoo.com.ar Fecha: jueves, 18 de diciembre de 2008, 10:55 am Leandro, Me parece que seguís pensando con el mismo modelo de los mails anteriores. Si tenés un cliente que puede acceder a una base de datos para hacer un CRUD sin que se exponga ninguna lógica de negocios: A) tenés un ABM que no sirve más que para trabajar con registros. En ese caso hay procesos mucho más interesantes y complejos que realizar en el mundo con lo cuál las aplicaciones diseñadas en N capas van a seguir existiendo por mucho tiempo. B) En realidad tenés un cliente que accede a la base de datos para trabajar con registros despuès de que los procesa con cierta lógica. Con lo cuál tenés una lógica de negocios embebida en tu cliente. ----- Original Message ----- From: Leandro Tuttini [mailto:ltuttini_lis...@yahoo.com.ar] To: patrones@mug.org.ar Sent: Thu, 18 Dec 2008 04:29:42 -0800 (PST) Subject: [patrones] Fwd: Desarrollo n capas, morira en el futuro ? 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 Visitá http://ar.mujer.yahoo.com/cocina/ Yahoo! Cocina Recetas prácticas y comida saludable http://ar.mujer.yahoo.com/cocina/
