[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 per
[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 repositorio. > > Se que mietras se diseña no se piensa en relaciones pero > es simplemente para contarles la p
[patrones] Repository asignacion de responsabilidad
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 <[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 e
[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
Leandro: Como vos me tope mucha veces con este problema ya que si uno lo mira desde la perspectiva de base de datos es simple y si lo mira desde la perspectiva desde el modelo del dominio se complica. Como siempre te tengo que decir que depende cada caso ,y no por tirar una frase echa, muchas veces el mismo modelo de base de datos termino siendo dos modelos de dominio no tan iguales en diferentes contextos. Pero para no ser tan teorico te diría los puntos que yo tomaría en cuenta, considerando obviamente los datos que logro entender de tu email y pidiendo disculpas por adelanto de la redacción :) Como se usa: Más bien es la lógica con la que uso los datos (mejor dichos conceptos el cliente). a- Seguramente se deber saber que límites tiene una cuenta. Esto te llema a que en el respositorio de una cuenta te traiga los limites de la la misma: RepositotioCuenta.GetLimite(cuentaId) b- Querras conocer los limites de las distintas cuentas organizado por timpo de limite RepositorioCuenta.GetLimites() En todos los casos anteriores siempre tenes la cuenta y con sus datos obtenes el limite, es decir, siempre estas parado en el contexto de la cuenta para acceder a un limite. En tu ejemplo de repositirios estas pensando que accedes al tipo limite teniendo el id de la cuenta, ¿pero que pasa si te dan el dni de algunos de los propietarios? , vas a poner otro medoto en el repositorio del limite para obtener por dni (teniendo en cuenta para este ejemplo que un dni sólo puede tener una cuenta para simplificar) o vas al repositorio de la cuenta para obtener el id y despues obtener el límite? Para mi lo más prolijo sería poner en el repositorio RepositorioCuenta.GetLimetes(dni) . O tener un lazy load en el aggregate de cuenta como antes te indico Carlos en un email. "Que despues tecnicamente el respositorio de la cuenta acceda al dao del limite para obtener los datos es otro tema, los repositorios en del domain model están precisamente para abstraerme de estos asuntos (tecnicos)" Saludos, Pablo. - Mensaje original De: Leandro Tuttini <[EMAIL PROTECTED]> Para: patrones List Member Enviado: martes 24 de julio de 2007, 14:42:29 Asunto: [patrones] Repository asignacion de responsabilidad Sebastian, muchas gracias por la respuesta. Te comento, el tema es que la clases que estos nombrando no son agregados, solo se relacionan mediante asociacion, ya que ambas pueden existir sin la existencia de la otra clase. O sea los limites se crean y persisten solitos, al igual que las clases, pero en algun momentos uno se asocia al otro. La cuestion es saber donde colocar los metodos en el respositorio en cual de los dos es correcto que este. O sea se debe hacer : LimiteTipoRepository.GetByCuenta(cuentaId); CuentaRepository.GetLimites(); Los dos metodos por supuesto devuelven un List. Saludos "Sebastian Renzi (Listas)" <[EMAIL PROTECTED]> escribió: Hola Leandro como andas?, te voy a comentar como lo suelo hacer yo, esto no quiere decir que sea lo correcto ni mucho menos. Como regla los value objects y los agregados no tienen repositorios propios, solo los entity los tienen, entonces en tu caso particular según mi vision, la responsabilidad seria de tu repositorio de Clases. Salu2 De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Leandro Tuttini Enviado el: Martes, 24 de Julio de 2007 10:11 a.m. Para: patrones List Member Asunto: [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á conse
[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á consejos para cuidar el lugar donde vivimos.. - ¡Sé un mejor fotógrafo! Perfeccioná tu técnica y encontrá las mejores fotos.
[patrones] Repository asignacion de responsabilidad
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..
[patrones] Repository asignacion de responsabilidad
Sebastian, muchas gracias por la respuesta.
Te comento, el tema es que la clases que estos nombrando no son agregados,
solo se relacionan mediante asociacion, ya que ambas pueden existir sin la
existencia de la otra clase.
O sea los limites se crean y persisten solitos, al igual que las clases, pero
en algun momentos uno se asocia al otro.
La cuestion es saber donde colocar los metodos en el respositorio en cual de
los dos es correcto que este.
O sea se debe hacer :
LimiteTipoRepository.GetByCuenta(cuentaId);
CuentaRepository.GetLimites();
Los dos metodos por supuesto devuelven un List.
Saludos
"Sebastian Renzi (Listas)" <[EMAIL PROTECTED]> escribió:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
Hola Leandro como andas?, te voy a comentar como lo suelo hacer yo,
esto no quiere decir que sea lo correcto ni mucho menos.
Como regla los value objects y los agregados no tienen repositorios propios,
solo los entity los tienen, entonces en tu caso particular según mi vision, la
responsabilidad seria de tu repositorio de Clases.
Salu2
-
De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Leandro Tuttini
Enviado el: Martes, 24 de Julio de 2007 10:11 a.m.
Para: patrones List Member
Asunto: [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..
-
¡Sé un mejor ambientalista!
Encontrá consejos para cuidar el lugar donde vivimos..
[patrones] Repository asignacion de responsabilidad
Hola Leandro como andas?, te voy a comentar como lo suelo hacer yo, esto no quiere decir que sea lo correcto ni mucho menos. Como regla los value objects y los agregados no tienen repositorios propios, solo los entity los tienen, entonces en tu caso particular según mi vision, la responsabilidad seria de tu repositorio de Clases. Salu2 _ De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Leandro Tuttini Enviado el: Martes, 24 de Julio de 2007 10:11 a.m. Para: patrones List Member Asunto: [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 /mejorambientalista.html> consejos para cuidar el lugar donde vivimos..
[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..
