[patrones] Repository asignacion de responsabilidad
Hola Leandro, Yo uso solo estos dos lineamientos para definir la interfaz de un repositorio: - En general, cada aggregate root, tiene su repositorio. - La interfaz del repositorio es similar a la de una coleccion. Es una coleccion de objetos del tipo del aggregate root. Sus metodos serian: Add(), Remove(), GetById(), GetByCriteria(), etc. En otras palabras, siempre que necesites una o mas instancias del aggregate root deberias accederlas mediante el repositorio con el query correspondiente. Carlos _ From: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Leandro Tuttini Sent: Miércoles, 25 de Julio de 2007 10:36 a.m. To: patrones List Member Subject: [patrones] Repository asignacion de responsabilidad Hola Carlos, gracias por la repuesta. Es mas o menos es lo que me imaginaba, poner el metodo que devuelve la lista de tipos de limite asociado a la cuenta en el repositorio de tipo de limite. Por supuesto la entidad cuenta tendra su propiedad que devuelva esta lista de tipos, pero lo hara mediante la interfaz del repositorio de tipos de limite y de seguro algun Factory. La logica aplicada es mas o menos la que mencionaba, o sea se analiza lo que se devuelve y se asigna la responsabilidad a la clase que meneja esta, o hay algo mas genericos?. Gracias Carlos Peix [EMAIL PROTECTED] escribió: Hola Leandro, En el caso que describis el metodo, si fuese necesario, iria en el repositorio de tipos de limite.Sin embargo, creo que el repositorio de cuentas deberia deveolver una cuenta con su coleccion de tipos de limite, usando Lazy load por ejemplo. Carlos _ From: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Leandro Tuttini Sent: Martes, 24 de Julio de 2007 10:11 a.m. To: patrones List Member Subject: [patrones] Repository asignacion de responsabilidad Hola, que tal. Me surgio una duda que es mas bien conceptual o de diseño y no tan tecnica. Les planteo la situacion a ver que resultado se puede obtener. Resulta que durante el diseño de la persistencia surgieron dudas que es dificil ver que es lo correcto. Tengo por ejemplo una clase de nombre Cuenta, que por supuesto tiene su repositorio, esta clase se une por medio de una relacion mucho a mucho con la clase Tipo de Limites, que por supuesto tambien tiene su repositorio. Se que mietras se diseña no se piensa en relaciones pero es simplemente para contarles la problematica. La cuestion es si debo agregar el metodo para recuperar la lista de tipos de limites asociados a la cuenta, donde deberia agregarse este metodo?, o sea en que repositorio. La logica indica que el metodo devolvera una lista de tipos de limites, (previo pasaje del identidicador de cuenta), por lo que deberia ir en el repositorio de Tipos de limites. Pero tambien sabemos que las cuentas por su relacion con los tipos de limites seran las unicas interesadas en recuperar esta relacion, por lo que agregarlo al repositorio de cuentas no estaria del todo mal. La cuestion es, cual es la correcta. Bueno como veran no es una pregunta tecnica, sino mas bien de diseño, como se deberia razonar en estos casos. Gracias Saludos _ ¡Sé un mejor ambientalista! Encontrá http://us.rd.yahoo.com/mail/ar/tagline/beabetter/*http://ar.yahoo.com/promos/me jorambientalista.html consejos para cuidar el lugar donde vivimos.. _ ¡Sé un mejor fotógrafo! Perfeccioná http://us.rd.yahoo.com/mail/ar/tagline/beabetter/*http://ar.yahoo.com/promos/me jorfotografo.html tu técnica y encontrá las mejores fotos.
[patrones] Repository asignacion de responsabilidad
En el caso que planteas, es asi como yo los armo, un repositorio para cada aggregate, independientemente del tipo de query que necesites hacer. En otras palabras, el repositorio debe devolver siempre el mismo tipo, o coleccion de ese tipo. Carlos _ From: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Leandro Tuttini Sent: Jueves, 26 de Julio de 2007 03:09 p.m. To: patrones List Member Subject: [patrones] Repository asignacion de responsabilidad Mil gracias a todos por las respuestas, la verdad son de mucha ayuda, para acercarse a la verdad. En resumen, si es un agregate deberia este repositorio (en este caso el de cuentas) quien maneje a la entidad y su agregado, por ejemplo, al guardarse, lo haga de los dos en este caso la cuenta y sus tipos asociados. Deberia llamar a dos store procedure, por ejemplo, o ejecutar dos insert sql, pero sin tener el repositorio de TiposLimites. Ahora si son dos tipos que solo se asocian cada uno deberia tener su propio repositorio cada entidad, (o sea es este caso que plantee), y es por medio de repositorio de TiposLimites que deberia recuperar la lista asociada con una cuenta en particular. En este caso cada llamada a store procedure, o insert sql, estaran en cada repositorio separado. Seria asi, o nuevamente le estoy errando. Saludos Pedro Wood [EMAIL PROTECTED] escribió: Hola Leandro, Para mi un repositorio es específico de un tipo, es un repositorio de algo y ese algo es 1 tipo en particular. O sea un repositorio devuelve un tipo en particular. Claro que el tipo podría ser una jerarquía de clases o un interfaz con diferentes implementaciones. Pero un RepositorioDeCuenta (o quizás un Repositorio), ya te indica qué es lo que devuelve, o un objeto Cuenta o una colección de objetos Cuenta. Podría ser que Cuenta tenga 2 o más subtipos y uses un sólo repositorio, con lo cual te devolvería CuentaX y CuentaY, pero no que devuelva otro tipo como TipoDeLimite. (Esto por más que tengas implementado un repositorio genérico, porque igual le tendrías que pasar el tipo que querés que te devuelva y eso otra vez lo convierte en un repositorio de un tipo en particular). Después si Cuenta tiene alguna relación con TipoDeLimite es otro tema. Si es parte de un aggregate entonces lo traerá directamente el ORM o el mapper. Pero si en tu caso es un root de un aggregate entonces para mi tenés que pasar a través del repositorio de TipoDeLimite. Saludos, Pedro Carlos Peix escribió: Hola Leandro, Yo uso solo estos dos lineamientos para definir la interfaz de un repositorio: - En general, cada aggregate root, tiene su repositorio. - La interfaz del repositorio es similar a la de una coleccion. Es una coleccion de objetos del tipo del aggregate root. Sus metodos serian: Add(), Remove(), GetById(), GetByCriteria(), etc. En otras palabras, siempre que necesites una o mas instancias del aggregate root deberias accederlas mediante el repositorio con el query correspondiente. Carlos *From:* patrones@mug.org.ar [mailto:[EMAIL PROTECTED] *On Behalf Of *Leandro Tuttini *Sent:* Miércoles, 25 de Julio de 2007 10:36 a.m. *To:* patrones List Member *Subject:* [patrones] Repository asignacion de responsabilidad Hola Carlos, gracias por la repuesta. Es mas o menos es lo que me imaginaba, poner el metodo que devuelve la lista de tipos de limite asociado a la cuenta en el repositorio de tipo de limite. Por supuesto la entidad cuenta tendra su propiedad que devuelva esta lista de tipos, pero lo hara mediante la interfaz del repositorio de tipos de limite y de seguro algun Factory. La logica aplicada es mas o menos la que mencionaba, o sea se analiza lo que se devuelve y se asigna la responsabilidad a la clase que meneja esta, o hay algo mas genericos?. Gracias */Carlos Peix /* escribió: Hola Leandro, En el caso que describis el metodo, si fuese necesario, iria en el repositorio de tipos de limite.Sin embargo, creo que el repositorio de cuentas deberia deveolver una cuenta con su coleccion de tipos de limite, usando Lazy load por ejemplo. Carlos *From:* patrones@mug.org.ar [mailto:[EMAIL PROTECTED] *On Behalf Of *Leandro Tuttini *Sent:* Martes, 24 de Julio de 2007 10:11 a.m. *To:* patrones List Member *Subject:* [patrones] Repository asignacion de responsabilidad Hola, que tal. Me surgio una duda que es mas bien conceptual o de diseño y no tan tecnica. Les planteo la situacion a ver que resultado se puede obtener. Resulta que durante el diseño de la persistencia surgieron dudas que es dificil ver que es lo correcto. Tengo por ejemplo una clase de nombre Cuenta, que por supuesto tiene su repositorio, esta clase se une por medio de una relacion mucho a mucho con la clase Tipo de Limites, que por supuesto tambien tiene su
[patrones] Repository asignacion de responsabilidad
Hola, que tal. Me surgio una duda que es mas bien conceptual o de diseño y no tan tecnica. Les planteo la situacion a ver que resultado se puede obtener. Resulta que durante el diseño de la persistencia surgieron dudas que es dificil ver que es lo correcto. Tengo por ejemplo una clase de nombre Cuenta, que por supuesto tiene su repositorio, esta clase se une por medio de una relacion mucho a mucho con la clase Tipo de Limites, que por supuesto tambien tiene su repositorio. Se que mietras se diseña no se piensa en relaciones pero es simplemente para contarles la problematica. La cuestion es si debo agregar el metodo para recuperar la lista de tipos de limites asociados a la cuenta, donde deberia agregarse este metodo?, o sea en que repositorio. La logica indica que el metodo devolvera una lista de tipos de limites, (previo pasaje del identidicador de cuenta), por lo que deberia ir en el repositorio de Tipos de limites. Pero tambien sabemos que las cuentas por su relacion con los tipos de limites seran las unicas interesadas en recuperar esta relacion, por lo que agregarlo al repositorio de cuentas no estaria del todo mal. La cuestion es, cual es la correcta. Bueno como veran no es una pregunta tecnica, sino mas bien de diseño, como se deberia razonar en estos casos. Gracias Saludos - ¡Sé un mejor ambientalista! Encontrá consejos para cuidar el lugar donde vivimos..
