Tiene sentido una DAL con un ORM

[Juan Carlos Quijano Abad]

Buenas,

Desarrollo Web en las cuatro capas clásicas, a saber:

Representación

Negocio

Capa de DAtos

Entidades

Mi gran duda es, si estoy utilizando un ORM com Entity Frameworks 4.0, tiene sentido que tenga una capa DAL? No es tácita que es la que genera el ORM?

Es que se ahorra una barbaridad de código y duplicidades y sigue estando desacoplada la capa de datos de la capa de negocio ya que se encarga de ello el EF.

Qué pensáis?

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

GenbetaDev

[Walter Poch]

Hola Juan,

Yo después de leer y releer blogs, y algunos libros me inclino por EOQ de Fabio (http://fabiomaulo.blogspot.com/2010/07/enhanced-query-object.html).

Creo que queda bien encapsulado el acceso a la DB, y es fácil de mockear en el controller, además accedes a todas las features de tu ORM.

Además se pueden ir generando a nivel feature de la aplicación.

Saludos,

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

--
Saludos,

Walter G. Poch
Sr. .Net Developer
--------------------------------------------
Cell: +54 (9 341) 3353273
walte...@gmail.com

[Juan Nallar]

Te cuento cómo lo uso yo...

Las clases de mi ORM son POCOS,  (serían tus entidades)

Mi DAL se divide en 2 capas, la que genera el ORM (cerca de la base de datos), y la que genero yo (cerca del negocio).

 

En ésta última, tengo métodos (que me devuelven mis entidades, en colecciones o no) y ademas encapsulo el CUD (por si la entidad tiene hijos).

 

Mi negocio sólo conoce ésta capa (que llamo Repositorio), y las entidades.

 

Saludos !

[Juan Carlos Quijano Abad]

Pero, Jesús, entonces si actualizas el modelo del ORM tienes que actualizar las POCO a mano?

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

GenbetaDev

[Germán Schuager]

Buenas,

Yo he trabajado en proyectos con y sin abstracción de la tecnología de acceso a datos, y en general me parece como vos bien decis, que usar el ORM directamente desde la capa de aplicación (o negocio) es lo más conveniente.

A pesar de esto, entiendo que según la complejidad y la cantidad de lógica involucrada, hay proyectos que pueden beneficiarse más que otros de esta abstracción.

En particular tengo la experiencia de un proyecto que se arrancó con el acceso a datos encapsulado detrás de un DAO genérico+EQOs (usando NH) y a medida que se avanzó en el desarrollo se fue filtrando el ORM hacia la capa de aplicación (por ej. para definir distintas estrategias de fetching para un "mismo" query o para usar la funcionalidad de queries futuros de NH).

De a poco dejamos de usar la abstracción y nos dimos cuenta que usar directamente el ORM es mucho más sencillo y no aporta ninguna desventaja.

Cabe aclarar que los tests de la capa de aplicación de este proyecto se realizan directamente contra una DB.

A partir de ese proyecto, trabajé en otros en los cuales obvié la abstracción del acceso a datos desde el inicio y la verdad es que estoy más que conforme con este tipo de arquitectura, principalmente por la simplicidad que presenta.

Saludos,

Germán.

2011/10/26 Walter Poch <walte...@gmail.com>

[Juan Nallar]

Ja, no.

Es algo así: http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

[Cristian Prieto]

Comence a escribir una simple respuesta, pero al final termino siendo tan larga que mejor la pase a la posteridad en mi blog...

http://cprieto.com/index.php/2011/10/28/el-espejismo-de-la-separacion-por-capas-toma-dos/

Desarrollar "en capas" es ortodoxo, obsoleto y retrogrado. En un mundo contemporaneo hablamos de dominios y tareas, no en capas.

Cristian Prieto

2011/10/27 Juan Nallar <nalla...@gmail.com>

[Juan Carlos Quijano Abad]

Muy bueno!!

Me lo estaba temiendo y ahora lo tengo clarísimo... cambio de rumbo timonel!!

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

GenbetaDev

[Carlos Peix]

Cristian,

"Algún día ordenare todos mis pensamientos y terminare escribiendo un poco más sobre porque el concepto de layer sigue siendo obsoleto, por lo menos para mí."

Espero ansioso ya que, mas alla de la reseña historica con la que estoy de acuerdo, en dos lecturas no entendi la conexion entre el postulado ("la separacion en capas es un espejismo") y sus justificaciones. Tampoco logre entender la conexion entre "la capa de acceso a datos", "objetos ricos en comportamiento", "consultas escritas en linq", etc. Basicamente, no entendi el 8vo parrafo.

De todas maneras prometo leerlo por tercera vez durante el fin de semana y vuelvo :-).

De todas maneras, gracias Cristian por tomarte el tiempo de escribirlo.

Abrazo

----------------------------------
Carlos Peix

2011/10/28 Cristian Prieto <keme...@gmail.com>

[Cristian Prieto]

Perdon Carlos, digamos que mi cabeza a veces es como las obras de James Joyce, un eterno Stream of consciousness (http://en.wikipedia.org/wiki/Stream_of_consciousness_(narrative_mode)) y tristemente suelo escribir como hablo, o sea, muy rapido y con mil y un ideas juntas...

Prometo mejorar mi redaccion la proxima vez, ya decia mi madre que tenia que poner atencion y no dormirme en las clases de espanol...

Ninos, ven porque es importante aprender a escribir?

NOTA: Realmente el titulo esta mas relacionado con el primer post que escribi hace mas de un anio donde hablaba del espejismo de presentar una aplicacion con capas, y en vez de crear un titulo nuevo simplemente le puse la "parte dos"... Mi error, gracias por notarlo!

Cristian Prieto

2011/10/28 Carlos Peix <carlo...@gmail.com>

[Carlos Peix]

Jajajajaja, leer y criticar es mas facil que escribir.

Mea culpa.

Un abrazo

[Victor Mingueza]

Hola Juan Quijano,

  Te explico un poco lo que yo hago y por lo tanto pienso que es lo ideal.

   Yo tengo una librería externa que a través de interfaces genéricas que me abstrae de la lógica de cualquier ORM (IGenericDao), con la operaciones básicas necesarias para acceso a datos y tengo una implementación para cada ORM que puedo utilizar agregando una nueva interfaz que herede de la anterior añadiendo las nuevas opciones que este ORM me facilita (INHibernateGenericDao : IGenericDao), Criteria, MultiCriteria...... Con esto tengo una librería independiente del ORM que estoy utilizando para implementaciones con EF, EF Code First y NHibernate.

  Ahora bien, usar o no usar una capa de datos? Bueno para mi depende siempre del contexto de la aplicación y pienso que esta seria la tarea de un buen arquitecto, ver si una aplicación va a requerir una capa de datos propia o simplemente incorporar la librería mencionada y hacer uso de ella en la lógica de negocio. 

  Cuando veo bien que seria un buen punto tenerla independiente? Cuando sea por ejemplo una gran aplicación con un coste de desarrollo de un año o mas. O cuando va a ser una aplicación con un gran mantenimiento y versionado cada año. Imagínate un servicio para una gran aplicación con mas de 5000 lineas, un poco tedioso de mantener no?, No seria mejor encapsular la lógica de acceso a datos, como consultas, preparación de objetos linq, paginado... en una capa independiente de la lógica de negocio y tener un servicio mas limpio y por lo tanto fácil de mantener?.

  En resumen, es bueno usar una capa independiente de acceso a datos? Pues depende, siempre depende :-)

[Gustavo Ringel]

Hacer interfaces para wrappear el ORM te quita toda la ventaja de usar un ORM...no es una buena idea seguro que no con NH hacer eso.

Lo mejor es en las clases que se encargan de acceso a datos recibir un SessionFactory y usar toda la fuerza del ORM.

Yendo con ideas como EQO de Fabio tenes la capacidad de implementar un Query con NH con EF con ADO directo o como sea, sin necesidad de generar una capa que abtraer otra capa que abstrae otra capa...

Gustavo.

2011/10/29 Victor Mingueza <victorm...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/nJdAOxB-lw8J.

[Victor Mingueza]

Puede parecer una mala idea, pero cuando abstraes el ORM que hay por detrás, te permite reutilizar muchos aspectos comunes en las aplicaciones que requieren de acceso a datos. y no pierdo la potencia del ORM porque en aquella aplicación donde lo necesito solo tengo que usar la interfaz concreta del ORM y no la Genérica de todos los ORMs.

Te enumero un par de puntos que no tendrías que replicar en cada aplicación con esta forma, tratamiento de excepciones, logs, gestión de tareas en segundo plano, ademas de otros puntuales que dependen un poco mas del negocio propio que no voy a enumerar aquí no siendo necesarios.

Saludos,

[Cristian Prieto]

No se, yo tengo solo una pregunta para los que abstraen el ORM...

Que tan seguido lo cambian?

Cristian Prieto

2011/10/29 Victor Mingueza <victorm...@gmail.com>

Puede parecer una mala idea, pero cuando abstraes el ORM que hay por detrás, te permite reutilizar muchos aspectos comunes en las aplicaciones que requieren de acceso a datos. y no pierdo la potencia del ORM porque en aquella aplicación donde lo necesito solo tengo que usar la interfaz concreta del ORM y no la Genérica de todos los ORMs.

Te enumero un par de puntos que no tendrías que replicar en cada aplicación con esta forma, tratamiento de excepciones, logs, gestión de tareas en segundo plano, ademas de otros puntuales que dependen un poco mas del negocio propio que no voy a enumerar aquí no siendo necesarios.

Saludos,

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/Do3sSWnNdt0J.

[Victor Mingueza]

Creo que al final se esta desviando un poco el tema, de la pregunta original, que es usar o no capa de datos independiente. (Como siempre pasa con esto, empezarían a hacer falta cervezas jaja)

De todas formas te indico que ahora mismo estamos desarrollando aplicaciones en los 3 ORMs indicados. Cada uno tiene unos puntos fuertes frente a otros, la ventaja es dejar transparente el uso de los mismos para el programador, lo cual no requiere de un largo proceso de aprendizaje al usar una misma interfaz genérica para el 70 o 80% de las operaciones con BB.DD.

Habiendo reducido el proceso de cambio de una  a otra tecnología, porque no aprovechar cada una en su mejor versión, para reducir los tiempos de desarrollo o mejorar el mantenimiento posterior?

[Cristian Prieto]

Bueno, regresando a la pregunta original:

"Tiene sentido usar o no una capa de datos independiente?"

Mi respuesta, No, es una abstracion inecesaria. Es un repositorio parte de tu capa de datos? No, es parte de tu dominio de negocio. Es necesario un repositorio abstracto? No, quizas uno con acceso basico sin terminar creando un "Dios Repositorio" (ese es otro tema).

La abstracion es un arma de dos filos, usada apropiadamente resuelve tus problemas, abstrae demasiado y al final te cae la ola.

Cristian Prieto

2011/10/29 Victor Mingueza <victorm...@gmail.com>

Creo que al final se esta desviando un poco el tema, de la pregunta original, que es usar o no capa de datos independiente. (Como siempre pasa con esto, empezarían a hacer falta cervezas jaja)

De todas formas te indico que ahora mismo estamos desarrollando aplicaciones en los 3 ORMs indicados. Cada uno tiene unos puntos fuertes frente a otros, la ventaja es dejar transparente el uso de los mismos para el programador, lo cual no requiere de un largo proceso de aprendizaje al usar una misma interfaz genérica para el 70 o 80% de las operaciones con BB.DD.

Habiendo reducido el proceso de cambio de una  a otra tecnología, porque no aprovechar cada una en su mejor versión, para reducir los tiempos de desarrollo o mejorar el mantenimiento posterior?

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/vZe0svhod14J.

[Fabio Maulo]

Hola.

Como yo salgo muy poco, despues de varios años yendo trás repositories, daos, EQOa y sus compañeros los inumerables services, application services, BusinessObjects, Active-Record y que se yo, estoy volviendo a trabajar como hacía un tiempo.

La view usa models que pueden ser suyo (view-model acomodados por el controler) o directamente modelo generados por el use-case.

El use-case usa Daos/Repositories/EQOs y solo devuelve el modelo de ese caso de uso (la famosa: jamon, queso y tomate).

Entidades, interfaces de EQOs/Repositories/DAOs, interfaces de use-case (si necesaria), implementacciones de use-case, modelos de use-case, messages de DomainEvents y mappers entre entidades<->model estan todos en el mismo assembly. Las view y los view-model (lo que son necesarios) están el el prj web. Las implementacciones de los DAOs/EQOs/Repositories están en uno o mas assemblies (tengo algunos DAOs/EQOs que trabajan a parte de con NH tambien con Azure-Tables y/o blob-storage). Las implementaciones de los handlers de los DomainEvents están desparramados en varios assemblies según corresponda.

El GuyWire se ocupa de cablear todo aunque, lamentablemente, aún uso IoC container (estoy cerca de hacerlo volar porque me cansé de explicar, cada vez que conozco un nuevo programador, donde está los "new" de algunas clases). Afortunadamente aún uso factories y serviceLocator así que no será dificil mantener DI y eliminar el IoC container.

Con eso estoy como Riquelme.

2011/10/26 Juan Carlos Quijano Abad <juancarl...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

--
Fabio Maulo

[José F. Romaniello]

con respecto a las capas yo estoy de acuerdo con Cristian, 

añado mis 2ctvs; TDD, Top-Down,  diseño emergente y evolución de la arquitectura

[Fabio Maulo]

Si, el tema es donde terminas mientras evoluciona.

Yo, en proyectos ASP.NET, terminé en lo que conté.

2011/10/29 José F. Romaniello <jfroma...@gmail.com>

--
Fabio Maulo

[Cristian Prieto]

Y quien es riquelme?

Cristian Prieto

2011/10/30 Fabio Maulo <fabio...@gmail.com>

[Jorge Fioranelli]

En mi opinión también hay que tener en cuenta como está conformado el equipo.

En equipos con un buen numero de  gente inexperimentada (juniors), tener una arquitectura pre-definida me ha dado mejor resultado que dejar que evolucione "naturalmente". A veces uno pierde mucho mas tiempo corrigiendo cosas mal hechas o unificando criterios (dos formas distintas para hacer lo mismo) que teniendo una arquitectura up-front definida (al menos un 70% de la arq, los detalles se van limando con el desarrollo).

Ahora si estamos hablando de equipos conformados por todos seniors, la cosa es distinta, todos suelen participar en el desarrollo de la arquitectura en la medida que se va necesitando.

Mis dos centavos

Saludos

JorgeF

[Juan Miguel]

Saludos cordiales a toda la comunidad, es un placer para mi escribir por primera vez y en un tema tan interesante y "candente".

Yo creo, que la respuestas a todas las preguntas y cuestiones planteadas es:

DEPENDE

La experiencia (aunque poca, comparada con los verdaderos monstruos y expertos que tenemos en la comunidad ;) ), me dice que la elección de una arquitectura, de una metodología, de un diseño, incluso de una tecnología y de herramientas depende de muchos factores:

1.- El cliente

2.- El equipo de trabajo

3.- La empresa, su filosofía, sus objetivos y sus principios

4.- El proyecto en si

5.- La experiencia, el conocimiento que puede albergar la organización al respecto.

(Lamento no poder explicar uno a uno, aunque me gustaría pero más que un correo sería un ensayo, y lo dejaré para mi blog, siguiendo el ejemplo de Cristian)

Creo que el software no hay nada escrito en "piedra", ni existe la solución perfecta a todos los problemas, y creo que es un error dejarse llevar por las modas.

En software hay principios y buenas prácticas, para casi todo, que te dicen que bajo ciertas condiciones (algunas están en la lista de arriba) te podría funcionar.  Pero estamos totalmente de acuerdo en que seguir esos principios y buenas prácticas no ayudan a que sea un éxito el proyecto, y si las "rompes" o "no las sigues" debes saber el porque y decirlo.

Así que DEPENDE.

Muchas gracias a todos por hacer de esta lista y comunidad un referente.

********************************
      Juan M. Palma V.               
********************************                                 
Madrid - España                 
El Conocimiento de la Humanidad,
pertenece al MUNDO ...               
*********************************

2011/10/30 Jorge Fioranelli <jorge.fi...@gmail.com>

[Cristian Prieto]

Hay algo que aprendi hace unos anios con varias personas de la comunidad, especialmente de nuestro amigo Fabio... No es que tu respuesta este mal y la mia mejor, es que simplemente esa es _mi_ respuesta y la otra _tu_ respuesta... Eso ha guiado mi vida profesional y he aprendido mucho gracias a ello =)

La otra que he aprendido en mis cortos anios de vida es simple, TODO depende, y es simple y sencillo, no solo de los factores que mencionas, si no de muchas otras cosas mas, como por ejemplo, es un pinche prototipo o es la mera app que vamos a meterle mano todo el tiempo? Cuanto tiempo tengo para hacerlo? Sabes o no sabes que estas haciendo? y hasta del lenguaje que pretendes usar... Vamos, depende hasta del clima, algunos programamos mejor cuando hace frio... (en mi caso soy fatal en climas humedos y calientes).

Ahora bien, yo 'crei' que la pregunta iba orientada a que piensa cada uno que debe ser, y en lo personal creo que todos mostramos nuestro punto de vista en esta thread que se ha tornado en una mas interesante de lo esperado... De hecho, gracias a mucho que se ha mencionado aqui y a la discusion de muchas otras personas (online, twitter, cara a cara) me he percatado de muchos otros puntos mas, es por eso que no cambio a la comunidad =)

Ahora bien, pongamos la pregunta en un contexto de "depende".

"Tiene sentido usar una DAL con un ORM?"

Depende:

1. Si usas un ORM es posible que tus companeros de trabajo esten mas acostumbrados a escribir LINQ que SQL o a ponerse a escribir codigo como locos, a nadie le gusta eso, entonces simplemente no, no tiene sentido.

2. Si todos han escrito codigo usando DAL's antes, tampoco, pueden hacerse a la idea que su 'DAL' es la ISession, o el DataContext, o el ObjectContext y simplemente usar el SaveChanges, Update, Delete, etc... expuesto, no veo razon para agregar otra capa mas

3. Si tu equipo es inexperimentado, no tiene sentido agregar una capa mas de abstracion a algo que ya es por si una abstracion de tus datos

4. Si tu equpo es experimentado, bueno, ahi es cuestion del gusto del equipo... He aprendido que entre equipos experimentados es casi imposible razonar y todos sacaran a relucir casos de uso, edge cases, experiencia anterior, malos entendidos y hasta el clima laboral... Asi que ahi si es como jugar una ruleta rusa y ver al final que decide el 'lider' del proyecto... tristemente.

Ahora bien, tambien depende de:

1. Si la empresa quiere que uses un DAL porque asi lo ha hecho siempre, no hay otra opcion, probablemente esa misma empresa este en contra de cosas como IOC, TDD, etc... y tendra siempre razones y las esgrimira para defenderlas, igual al caso 4 anterior.

2. Si ya existia una DAL anterior y debes simplemente continuarla, no hay otra opcion

3. Si con DAL se refieren a cosas como un Reposiorio (que no es una DAL) entonces convencete a ti mismo que estas trabajando en la DAL

Al final de cuentas todo depende, y uno debe aprender a cuando torcer el brazo cuando es necesario, o como me menciono un Lead Consultant en un proyecto una vez: "this is my project and you should do what I think it's the better, when you run your own do what you think it's right, not this time"... Asi que a veces depende como menciona Juan.

Igual, otro dia continuo el blog post... =)

Saludos!

Cristian Prieto

2011/10/30 Juan Miguel <jm.p...@gmail.com>

[Carlos Peix]

A mi me gusta abstraer la implementacion del acceso a datos pero me parece importante indicar el motivo.

Por ejemplo, no me gusta usar linq para realizar queries desde el codigo, en otras palabras, no me gusta publicar IQueryable fuera de la capa de acceso a datos. No tengo nada contra linq, todo lo contrario, pero no me gusta en el acceso a datos.

Por el mismo motivo, tampoco me gusta publicar otras formas de definicion de queries fuera de la capa de acceso a datos (HQL, ICriteria, etc).

El motivo es que he sufrido bastante a la hora de optimizar queries que estan definidos con la logica de negocios.

Por supuesto, como dice Cristian, cada uno tiene su opinion, solo comparto argumnetos para que cada cul decida.

Mi implementacion se basa en definir interfaces para un repositorio generico (metodos: Add, Delete y, eventualmente, GetById) y para los EQO que define Fabio. La implementacion de esas interfaces esta en un proyecto distinto y puede basarse en un ORM o no (usualmente, para mi, NH). Lo bueno es que, para cada query tengo la opcion de utilizar un mecanismo distinto de query sobre NH (named query, ICriteria, HQL, SQL, etc).

Esto hace que mis repositorios/queries no esten en una sola capa sino en dos. Las interfaces estan en el negocio, la implementacion en infraestructura, en lo que, usualmente, se llamaria la capa de acceso a datos.

Esta abstraccion me ha salbado varias veces.

Abrazo

----------------------------------
Carlos Peix

2011/10/30 Cristian Prieto <keme...@gmail.com>

[cibrax]

En mi caso particular, soy de los que piensan que una DAL es
innecesaria si tenes un ORM. Lo que veo por experiencia es que agregan
un poco de friccion en el desarrollo. Si ya tenes un ORM que te
abstrae bastante del motor de base de datos y resuelve todo el tema de
mapeo, no veo el punto de agregar una capa mas que complica o
restringe la capacidad de hacer queries en las capas superiores. Lo
que veo bien, es tener un repositorio sobre el ORM mas que nada para
poder testear el codigo que hace uso del mismo. Los repositorios que
implemento por lo general devuelven un IQueryable y no abstraen el ORM
que esta por debajo, pero facilitan el testeo.

Saludos
Pablo.

> 2011/10/30 Cristian Prieto <kement...@gmail.com>

[Carlos Peix]

Hola Esteban,

Por las dudas que fuera informacion sensible, acabo de eliminar tus dos mensajes del grupo. Desde ya que quedo en la cuenta de cada uno de nosotros, pero al menos no estara indexado en internet.

Abrazo

----------------------------------
Carlos Peix

2011/10/31 Esteban Grinberg <esteban....@gmail.com>

Perdon gente!

Entre tanto apuro y solapas abiertas, envie el anterior mail a destino equivocado.

Pero buen..., una razon mas para usar ORM y no SQL directo :)

[Vinicius de Melo Rocha]

Y si usted desea cambiar ORM? ¿No sería bueno tener una DAL?

2011/10/31 cibrax <cib...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

--
Vinicius de Melo Rocha

http://diveintocode.com
http://vmelorocha.wordpress.com/
http://twitter.com/vmrocha

[José F. Romaniello]

El 31 de octubre de 2011 12:53, Vinicius de Melo Rocha <vmr...@gmail.com> escribió:

Y si usted desea cambiar ORM? ¿No sería bueno tener una DAL?

Es muy complicado eso, cuando tenga que cambiar el ORM vas a tener que hacer varias cosas apartes. Por otro lado tal vez uno no quiera invertir esfuerzo en hacer algo "por si el día de mañana, tal vez, decidimos cambiar el ORM".

No estoy diciendo que abstraer una complejidad sea mal, estoy diciendo que esa razón en particular no la encuentro tan válida.

En cierta forma esto me recuerda a algunos guidelines, donde decían "la lógica de negocios la separamos así, por si algún día decidimos cambiar un front end de winform por uno de asp.net".