> 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.
> On Oct 30, 11:08 am, Carlos Peix <carlos.p...@gmail.com> wrote:
> > 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 <kement...@gmail.com>
> > > 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
> --
> 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-hispano@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a
> altnet-hispano+unsubscribe@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/altnet-hispano?hl=es.
