Hola, Yo sigo siendo partidario de no hacer mezclas extrañas, como aquí se expone. Lo que podría ser viable utilizando NH es que en algunas ocasiones uses ADO.NET tal cual o incluso mejor (posiblemente Enterprise Library Data Application Block), ya que con entlib puedes "abstraerte" del tipo de base de datos, igual (menos igual...) que con NH.
De NH puedes obtener el objeto de conexión a la base de datos y la transacción que se esté utilizando en el momento para interactuar con la bbdd desde otros puntos que no sean NH. De todas formas, esto te puede provocar problemas si el acceso ADO utiliza datos que también utiliza NH en el mismo momento. No lo recomiendo. En cuanto al uso de DAOs, que se comenta, no entiendo por qué puede limitarte. Si utilizas los DAOs mediante una interface y la instanciación a través de Castle, puedes agregar inspectors y demás temas de Castle que te dan una flexibilidad bestial. Además, usando la interface, podrías intercambiar un objeto DAO por otro que implemente la misma interface simplemente cambiando la configuración de castle. Lo que no comprendo, como en el ejemplo que pone, por qué puede ser que quieras grabar con NH y recuperar con ADO.NET... El tema se complica mucho más si es NH y EF... Posiblemente quieren poder determinar si un ADO, en toda su funcionalidad, accede de una forma u otra. En ese caso Castle es la respuesta y el uso de interfaces. No sin peligros... Si tu sistema va a ser grande... lo primero que se busca en la arquitectura es que exista una línea de desarrollo única. Las mezclas no son demasiado buenas... Lo del cliente siempre tiene la razón, creo que es determinando el color de fondo de una pantalla, no determinando las tripas. Suerte! On 22 feb, 14:18, jose ubaldo carvajal <[email protected]> wrote: > Muchas Gracias Carlos, me parece absolutamente cierto lo que dices y > entraremos a negociar esa parte con el cliente. > > El 21 de febrero de 2010 06:09, Carlos Peix <[email protected]>escribió: > > > > > Hola Jose, > > > Una cosa que me parece importante es que sepas que con una implementacion > > de DAO como la que mostraste en tu ejemoplo perdes un monton de ventajas de > > los ORMs (tanto NH como EF) que te van a complicar la vida (bah, el > > proyecto). > > > Lo que yo haria en tu posicion es preguntar al cliente porque pide una capa > > de acceso a datos como esa. Seguramente hay un motivo que no te ha dicho o > > que no nos has dicho y es muy probable que tenga otra soluciones. > > Definitivamente esta solucion me parece peligrosa. > > > Deben tener cuidado hasta cuando le hacen caso sumisamente al cliente, > > tengan en cuenta que si la arquitectura se complica, falla o se hace dificil > > de mantener, los culpables van a ser ustedes. No seria la primera vez que > > una peticion como esta de un cliente arruina un proyecto. > > > O acaso un cirujano acepta que el paciente quiera hacerse una cirugia > > cardiovascular en el living de su casa? > > > ---------------------------------- > > Carlos Peix > > > 2010/2/20 proxy <[email protected]> > > >> Saludos comunidad. > > >> En estos días, estamos diseñando en la empresa una arquitectura para > >> un proyecto ciertamente grande que incluye componentes móviles, WPF y > >> ASP.NET - MVC, además de un SIG. Ante lo cual optamos por una > >> separación en 4 capas: > > >> 1. presentación > >> 2. negocios > >> 3. acceso a datos > >> 4. forma de acceso a datos (NH, ADO.NET, EF..etc.) .... Aquí es donde > >> está el problema :( > > >> También unas capas transversales como servicios, comunicaciones y > >> seguridad. La arquitectura debe soportar nuevos módulos que se le irán > >> sumando con el tiempo. > > >> Naturalmente y por tantas razones que ya conocemos, optamos por > >> NHibernate con nuestra opción principal para ORM; sin embargo tenemos > >> un requerimiento del cliente: "Que la capa de datos sea flexible, para > >> poder realizar ciertas operaciones con la BD con ADO.NET"; o sea, algo > >> como esto: > > >> public class CustomerADO > >> { > >> public void Save() > >> { > >> //Implementación del save con NH. > >> } > > >> public Customer Retrieve() > >> { > >> //Retrieve -SQL- con ADO.NET > >> } > >> } > > >> O sea, nuestro cliente quiere algo completamente flexible en la parte > >> de acceso a datos, no le veo mucho sentido, pero finalmente no le > >> podemos decir que no. He pensado en algunos frameworks como SPRING.NET > >> para inyectar dependencias etc... Pero no tengo claro que tan posible > >> sea tener una capa de acceso a datos tan híbrida con NH, ADO.NET y en > >> un futuro EF. > > >> Esto es posible? > >> Hay un patrón de diseño que te solucione algo así? > >> Una implementación tan híbrida de la capa de acceso a datos dañaría la > >> arquitectura...? > > >> Muchas gracias por sus aportes. > > >> -- > > >> Para escribir al Grupo, hágalo a esta dirección: > >> [email protected] > >> Para más, visite:http://groups.google.com/group/NHibernate-Hispano > > > -- > > Para escribir al Grupo, hágalo a esta dirección: > > [email protected] > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
