domain o infrastructure?
4 views
Skip to first unread message
Raul Lopez
Dec 16, 2009, 6:15:35 AM12/16/09
to altnet-a...@googlegroups.com
Hola, tengo una duda respecto a la correcta ubicacion de ciertos
servicios en mi modelo.
La solucion consta de los siguientes proyectos: Application, Domain,
Infrastructure, Presentation, Tests.
normalmente tengo en mi modelo algo asi (simplificando)
public Departamento ObtenerDepartamento(int id)
{
Departamento departamento = new Departamento();
try {
using (ISession session = NHibernateHelper.OpenSession())
using (session.BeginTransaction()) {
CurrentSessionContext.Bind(session);
IDaoFactory daoFactory = new NHibernateDaoFactory();
IDepartamentoDao departamentoDao =
daoFactory.GetDepartamentoDao();
departamento =
departamentoDao.FindById(id);
...
}
} catch (HibernateException ex)
{
throw new
Infrastructure.Exceptions.InfrastructureException("Error al obtener
departamento", ex);
} finally {
CurrentSessionContext.Unbind(NHibernateHelper.SessionFactory);
}
return departamento;
}
Este metodo es consumido por un servicio de mas alto nivel (normalmente
en Application), que hace algo con el resultado, lo pasa a Presentation,
etc .... y tal como esta planteado funciona.
Pero... en realidad pertenece a domain o a infrastructure?
En la practica funciona como un repository (domain?) , pero tambien esta
manejando la session / transaccion y
por otro lado tiene dependencias de NH que no deberian estar en domain.
Actualmente lo tengo en domain y funciona, pero tengo mis dudas sobre si
esto esta bien asi.
Agradezco sugerencias
Saludos,
Raul
servicios en mi modelo.
La solucion consta de los siguientes proyectos: Application, Domain,
Infrastructure, Presentation, Tests.
normalmente tengo en mi modelo algo asi (simplificando)
public Departamento ObtenerDepartamento(int id)
{
Departamento departamento = new Departamento();
try {
using (ISession session = NHibernateHelper.OpenSession())
using (session.BeginTransaction()) {
CurrentSessionContext.Bind(session);
IDaoFactory daoFactory = new NHibernateDaoFactory();
IDepartamentoDao departamentoDao =
daoFactory.GetDepartamentoDao();
departamento =
departamentoDao.FindById(id);
...
}
} catch (HibernateException ex)
{
throw new
Infrastructure.Exceptions.InfrastructureException("Error al obtener
departamento", ex);
} finally {
CurrentSessionContext.Unbind(NHibernateHelper.SessionFactory);
}
return departamento;
}
Este metodo es consumido por un servicio de mas alto nivel (normalmente
en Application), que hace algo con el resultado, lo pasa a Presentation,
etc .... y tal como esta planteado funciona.
Pero... en realidad pertenece a domain o a infrastructure?
En la practica funciona como un repository (domain?) , pero tambien esta
manejando la session / transaccion y
por otro lado tiene dependencias de NH que no deberian estar en domain.
Actualmente lo tengo en domain y funciona, pero tengo mis dudas sobre si
esto esta bien asi.
Agradezco sugerencias
Saludos,
Raul
José F. Romaniello
Dec 16, 2009, 6:41:35 AM12/16/09
to altnet-a...@googlegroups.com
yo diría que pertenece al dominio... por que el objetivo del método pertenece al dominio.
Pero como vos te diste cuenta, esta tocando varios temas de infraestructura, que a mi criterio y viendo el nombre de las clases, diría que no deberían estar allí. Básicamente el problema que le veo a ese código es que tu servicio esta atado a nhibernate.
podrías tener algo así mejor:
public class ServicioNoSeQue{
private IDaoFactory _daoFactory;
public ServicioNoSeQue(IDaoFactory daoFactory){
_daoFactory = daoFactory;
}
public Departamento ObtenerDepartamento(int id){
return _daoFactory.GetDaoOf<Departamento>().GetById(id);
}
}
Como ves en este otro ejemplo, hay prácticamente nada de código de infraestructura. Y si funciona, de hecho mis servicios tienen esa pinta. Donde se abre y cierra la sesión?, donde se "bindea"?, donde se inicia la transacción? es un tema que da para hablar un buen rato.
El manejo de la excepción que tenes tampoco "lo compro".
--
Desuscripción: altnet-argenti...@googlegroups.com
Jorge E. Fioranelli
Dec 16, 2009, 7:19:53 AM12/16/09
to altnet-a...@googlegroups.com
Yo trato de manejar la sesión/contexto del ORM en los servicios de aplicación.
En el caso de las transacciones, si puedo usarlas a nivel de aplicación trato de usarlas ahí también.
Pero es cierto que a veces el negocio te lleva a tener transacciones más granulares que "todo el request", ahí capaz que conviene dejar la sesión/contexto accesible para el negocio o armar algún atributo para decorar los métodos transaccionales del negocio.
Saludos
Jorge
--
Desuscripción: altnet-argenti...@googlegroups.com
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.716 / Virus Database: 270.14.108/2566 - Release Date: 12/15/09 04:52:00
En el caso de las transacciones, si puedo usarlas a nivel de aplicación trato de usarlas ahí también.
Pero es cierto que a veces el negocio te lleva a tener transacciones más granulares que "todo el request", ahí capaz que conviene dejar la sesión/contexto accesible para el negocio o armar algún atributo para decorar los métodos transaccionales del negocio.
Saludos
Jorge
Desuscripción: altnet-argenti...@googlegroups.com
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.716 / Virus Database: 270.14.108/2566 - Release Date: 12/15/09 04:52:00
Carlos Peix
Dec 16, 2009, 7:21:49 AM12/16/09
to altnet-argentina
Hola Raul,
Yo agregaria una aclaracion a lo que dice Jose ya que me parece que el esta dando algo por entendido.
Jose rearmo tu codigo pero tambien, si no me equivoco, lo movio desde la capa de modelo (como vos habias propuesto) a la capa de servicio de aplicacion (no confundir con servicios del modelo de dominio).
Estimo que este servicio que propone Jose deberia estar en la capa que de has definido como capa de Aplicacion. Fijate que el codigo que vos mandaste originalmente no tiene ninguna logica de negocio, cosa que se ve mas clara en la version de Jose.
--
Desuscripción: altnet-argenti...@googlegroups.com
Raul Lopez
Dec 16, 2009, 8:17:00 AM12/16/09
to altnet-a...@googlegroups.com
Hola Carlos,
Como vos decis, el metodo no tiene logica de negocio. Su funcion es
retornar a aplicacion algo que debe solicitar a infraestructura, y si
bien la version de Jose mejora notoriamente el ejemplo que yo envie al
suprimir lo relacionado con NH, creo que deberia seguir estando como un
servicio de dominio.
Esto me lleva al punto de donde seria mejor manejar la session /
transaccion / binding y ahi coincido con Jorge en que la capa de
aplicacion me gusta mas para eso.
Entonces armaria la sesion/transaccion en aplicacion y luego invocaria
este servicio (en domain) inyectandole las dependencias de
infraestructura necesarias.
Con ese esquema estaria incluyendo referencias a NH y a infraestructura
en la capa de aplicacion pero me hacen menos ruido ahi que en domain.
Saludos,
Raul.
Carlos Peix escribi�:
> <mailto:jfroma...@gmail.com>>
>
> yo dir�a que pertenece al dominio... por que el objetivo
> del m�todo pertenece al dominio.
> que le veo a ese c�digo es que tu servicio esta atado a nhibernate.
>
> podr�as tener algo as� mejor:
> donde se inicia la transacci�n? es un tema que da para hablar un
> buen rato.
>
> El manejo de la excepci�n que tenes tampoco "lo compro".
> Desuscripci�n: altnet-argenti...@googlegroups.com
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>
>
>
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>
>
>
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
Como vos decis, el metodo no tiene logica de negocio. Su funcion es
retornar a aplicacion algo que debe solicitar a infraestructura, y si
bien la version de Jose mejora notoriamente el ejemplo que yo envie al
suprimir lo relacionado con NH, creo que deberia seguir estando como un
servicio de dominio.
Esto me lleva al punto de donde seria mejor manejar la session /
transaccion / binding y ahi coincido con Jorge en que la capa de
aplicacion me gusta mas para eso.
Entonces armaria la sesion/transaccion en aplicacion y luego invocaria
este servicio (en domain) inyectandole las dependencias de
infraestructura necesarias.
Con ese esquema estaria incluyendo referencias a NH y a infraestructura
en la capa de aplicacion pero me hacen menos ruido ahi que en domain.
Saludos,
Raul.
Carlos Peix escribi�:
> Hola Raul,
>
> Yo agregaria una aclaracion a lo que dice Jose ya que me parece que el
> esta dando algo por entendido.
>
> Jose rearmo tu codigo pero tambien, si no me equivoco, lo movio desde
> la capa de modelo (como vos habias propuesto) a la capa de servicio de
> aplicacion (no confundir con servicios del modelo de dominio).
>
> Estimo que este servicio que propone Jose deberia estar en la capa que
> de has definido como capa de Aplicacion. Fijate que el codigo que vos
> mandaste originalmente no tiene ninguna logica de negocio, cosa que se
> ve mas clara en la version de Jose.
>
> ----------------------------------
> Carlos Peix
>
> 2009/12/16 Jos� F. Romaniello <jfroma...@gmail.com
>
> Yo agregaria una aclaracion a lo que dice Jose ya que me parece que el
> esta dando algo por entendido.
>
> Jose rearmo tu codigo pero tambien, si no me equivoco, lo movio desde
> la capa de modelo (como vos habias propuesto) a la capa de servicio de
> aplicacion (no confundir con servicios del modelo de dominio).
>
> Estimo que este servicio que propone Jose deberia estar en la capa que
> de has definido como capa de Aplicacion. Fijate que el codigo que vos
> mandaste originalmente no tiene ninguna logica de negocio, cosa que se
> ve mas clara en la version de Jose.
>
> ----------------------------------
> Carlos Peix
>
> <mailto:jfroma...@gmail.com>>
>
> yo dir�a que pertenece al dominio... por que el objetivo
> del m�todo pertenece al dominio.
> Pero como vos te diste cuenta, esta tocando varios temas de
> infraestructura, que a mi criterio y viendo el nombre de las
> clases, dir�a que no deber�an estar all�. B�sicamente el problema
> infraestructura, que a mi criterio y viendo el nombre de las
> que le veo a ese c�digo es que tu servicio esta atado a nhibernate.
>
> podr�as tener algo as� mejor:
>
>
> public class ServicioNoSeQue{
>
> private IDaoFactory _daoFactory;
>
> public ServicioNoSeQue(IDaoFactory daoFactory){
> _daoFactory = daoFactory;
> }
>
> public Departamento ObtenerDepartamento(int id){
> return _daoFactory.GetDaoOf<Departamento>().GetById(id);
> }
> }
>
>
> Como ves en este otro ejemplo, hay pr�cticamente nada de c�digo de
>
> public class ServicioNoSeQue{
>
> private IDaoFactory _daoFactory;
>
> public ServicioNoSeQue(IDaoFactory daoFactory){
> _daoFactory = daoFactory;
> }
>
> public Departamento ObtenerDepartamento(int id){
> return _daoFactory.GetDaoOf<Departamento>().GetById(id);
> }
> }
>
>
> infraestructura. Y si funciona, de hecho mis servicios tienen esa
> pinta. Donde se abre y cierra la sesi�n?, donde se "bindea"?,
> donde se inicia la transacci�n? es un tema que da para hablar un
> buen rato.
>
> El manejo de la excepci�n que tenes tampoco "lo compro".
>
>
> El 16 de diciembre de 2009 08:15, Raul Lopez
> <rlope...@gmail.com <mailto:rlope...@gmail.com>> escribi�:
>
> El 16 de diciembre de 2009 08:15, Raul Lopez
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>
>
>
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>
>
>
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
José F. Romaniello
Dec 16, 2009, 8:34:59 AM12/16/09
to altnet-a...@googlegroups.com
En web se utiliza mucho por request, como dijo Jorge, aunque también como dijo Jorge a veces es necesario algo mas granular.
[PersistenceConversational]
public class ServicioNoSeQue{
private IDaoFactory _daoFactory;
public ServicioNoSeQue(IDaoFactory daoFactory){
_daoFactory = daoFactory;
}
[PersistenceConversation]
public Departamento ObtenerDepartamento(int id){
return _daoFactory.GetDaoOf<Departamento>().GetById(id);
}
}
Si este es tu caso, te aconsejo mirar los posts de Fabio al respecto, sobre todo este:
Otra cosa, después de leer lo que dice Carlos Peix, se me hizo lio entre "servicio de aplicación" y "servicio de modelo de dominio".
Este metodo es consumido por un servicio de mas alto nivel (normalmente en Application), que hace algo con el resultado, lo pasa a Presentation, etc .... y tal como esta planteado funciona.
Me parece que lo que vos estas llamando como "Servicio de aplicación" es un presenter o controller. Puede ser?
Sería algo así: View -> Presenter (Application Service) -> Domain Service -> Dao ??
Raul Lopez
Dec 16, 2009, 8:40:26 AM12/16/09
to altnet-a...@googlegroups.com
Si, despues de *responder* a Carlos y releer todo cuidadosamente a mi
tambien se me hizo lio con "servicio de aplicacion" y "servicio de dominio"
En realidad un servicio de dominio sin logica de negocio no tiene
sentido (creo :))
seria asi: [view -> presenter] -> Application -> Domain (repository?)
-> DAO
Jos� F. Romaniello escribi�:
> En web se utiliza mucho por request, como dijo Jorge, aunque tambi�n
> lo cual el c�digo que vos mandaste es mas o menos equivalente a esto:
> entre "servicio de aplicaci�n" y "servicio de modelo de dominio".
> Service -> Dao ??
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
tambien se me hizo lio con "servicio de aplicacion" y "servicio de dominio"
En realidad un servicio de dominio sin logica de negocio no tiene
sentido (creo :))
seria asi: [view -> presenter] -> Application -> Domain (repository?)
-> DAO
Jos� F. Romaniello escribi�:
> En web se utiliza mucho por request, como dijo Jorge, aunque tambi�n
> como dijo Jorge a veces es necesario algo mas granular.
>
> En winforms no hay algo como el request para demarcar cuando inicia o
> no una transacci�n, en realidad yo utilizo AOP para estas cosas. Con
>
> En winforms no hay algo como el request para demarcar cuando inicia o
> lo cual el c�digo que vos mandaste es mas o menos equivalente a esto:
>
> [PersistenceConversational]
> public class ServicioNoSeQue{
>
> private IDaoFactory _daoFactory;
>
> public ServicioNoSeQue(IDaoFactory daoFactory){
> _daoFactory = daoFactory;
> }
>
> [PersistenceConversation]
> public Departamento ObtenerDepartamento(int id){
> return _daoFactory.GetDaoOf<Departamento>().GetById(id);
> }
> }
>
> Si este es tu caso, te aconsejo mirar los posts de Fabio al respecto,
> sobre todo este:
> http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html
>
> Otra cosa, despu�s de leer lo que dice Carlos Peix, se me hizo lio
> [PersistenceConversational]
> public class ServicioNoSeQue{
>
> private IDaoFactory _daoFactory;
>
> public ServicioNoSeQue(IDaoFactory daoFactory){
> _daoFactory = daoFactory;
> }
>
> [PersistenceConversation]
> public Departamento ObtenerDepartamento(int id){
> return _daoFactory.GetDaoOf<Departamento>().GetById(id);
> }
> }
>
> Si este es tu caso, te aconsejo mirar los posts de Fabio al respecto,
> sobre todo este:
> http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html
>
> entre "servicio de aplicaci�n" y "servicio de modelo de dominio".
>
> Este metodo es consumido por un servicio de mas alto nivel
> (normalmente en Application), que hace algo con el resultado, lo
> pasa a Presentation, etc .... y tal como esta planteado funciona.
>
>
> Me parece que lo que vos estas llamando como "Servicio de aplicaci�n"
> Este metodo es consumido por un servicio de mas alto nivel
> (normalmente en Application), que hace algo con el resultado, lo
> pasa a Presentation, etc .... y tal como esta planteado funciona.
>
>
> es un presenter o controller. Puede ser?
> Ser�a algo as�: View -> Presenter (Application Service) -> Domain
> Service -> Dao ??
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
Leandro Boffi
Dec 16, 2009, 8:50:05 AM12/16/09
to altnet-a...@googlegroups.com
Jose,
En mi opinion ese codigo es tipico de un repositorio, el cual yo pongo dentro de la capa de dominio, igual que las factories. Como dice Jorge el contexto de NH, asi como las transacciones las manejaria en la capa de aplicacion, para no ensuciar el modelo, ya que son accidentes tecnologicos. Y no se si usaria un DAO, ya que usaria un repositorio.
Si fuese asi, podrias tener un servicio de aplicacion que tenga todo lo relacionado con nhibernate y que llame al repositorio.
Por otra parte un servicio de dominio para ser un servicio de dominio tiene que ser una operacion que no guarde estado, que aplique alguna regla del dominio o modifique algo dentro del dominio y que no quede natural ponersela a una entidad...
2009/12/16 José F. Romaniello <jfroma...@gmail.com>
En web se utiliza mucho por request, como dijo Jorge, aunque también como dijo Jorge a veces es necesario algo mas granular.
--
Desuscripción: altnet-argenti...@googlegroups.com
José F. Romaniello
Dec 16, 2009, 9:32:20 AM12/16/09
to altnet-a...@googlegroups.com
El 16 de diciembre de 2009 10:50, Leandro Boffi <lbo...@gmail.com> escribió:
Jose,En mi opinion ese codigo es tipico de un repositorio, el cual yo pongo dentro de la capa de dominio, igual que las factories.
Si y no y más o menos. El repositorio o dao para mi es backend, no siempre lo expongo directamente a mis controllers/presenters. Yo uso un servicio por cada caso de uso, si el caso de uso tiene obtener un departamento por ID, ahí estará algo así.
Como dice Jorge el contexto de NH, asi como las transacciones las manejaria en la capa de aplicacion, para no ensuciar el modelo, ya que son accidentes tecnologicos. Y no se si usaria un DAO, ya que usaria un repositorio.
No se que es capa de aplicación.
Si fuese asi, podrias tener un servicio de aplicacion que tenga todo lo relacionado con nhibernate y que llame al repositorio.
Jamas. Yo uso nhibernate para el acceso a datos nada más. Servicios y nhibernate no son palabras compatibles. El único lugar donde me permito usar nhibernate es en Daos y Repositorios.
Por otra parte un servicio de dominio para ser un servicio de dominio tiene que ser una operacion que no guarde estado, que aplique alguna regla del dominio o modifique algo dentro del dominio y que no quede natural ponersela a una entidad...
Bueno, a mi no me gusta esa definición de "servicio de dominio". Por que no tiene que tener estado?. Me parece que eso esta confundiendo "servicio físico" con otra cosa. No esta muy bueno tener estado en web services o wcf services pero esa es una limitación técnica.
José F. Romaniello
Dec 16, 2009, 9:35:22 AM12/16/09
to altnet-a...@googlegroups.com
Sobre Dao vs Repositorio.. que te puedo decir. Yo hice mi ejemplo con Repositorio, y la verdad que me trajo algunas complicaciones a la hora de mockearlo y en otros lugares que puedo detallar mas adelante en algún post.
Tu repositorio implementa la interface IEnumerable<>?
Raul Lopez
Dec 16, 2009, 9:44:14 AM12/16/09
to altnet-a...@googlegroups.com
se complico....
en este momento estaba llegando a la conclusion de que mi codigo si era
un repository....
veo al repository como un concepto de dominio y al dao como algo de
infraestructura, el dao es el que le pega directo al orm o lo que sea y
el repository tiene un nivel de abstraccion mayor
y por lo tanto mas independiente de la tecnologia.
Jos� F. Romaniello escribi�:
> <mailto:lbo...@gmail.com>> escribi�:
> nhibernate no son palabras compatibles. El �nico lugar donde me
> services o wcf services pero esa es una limitaci�n t�cnica.
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
en este momento estaba llegando a la conclusion de que mi codigo si era
un repository....
veo al repository como un concepto de dominio y al dao como algo de
infraestructura, el dao es el que le pega directo al orm o lo que sea y
el repository tiene un nivel de abstraccion mayor
y por lo tanto mas independiente de la tecnologia.
Jos� F. Romaniello escribi�:
> <mailto:lbo...@gmail.com>> escribi�:
>
> Jose,
>
> En mi opinion ese codigo es tipico de un repositorio, el cual yo
> pongo dentro de la capa de dominio, igual que las factories.
>
>
> Si y no y m�s o menos. El repositorio o dao para mi es backend, no
> Jose,
>
> En mi opinion ese codigo es tipico de un repositorio, el cual yo
> pongo dentro de la capa de dominio, igual que las factories.
>
>
> siempre lo expongo directamente a mis controllers/presenters. Yo uso
> un servicio por cada caso de uso, si el caso de uso tiene obtener un
> departamento por ID, ah� estar� algo as�.
> un servicio por cada caso de uso, si el caso de uso tiene obtener un
>
>
>
> Como dice Jorge el contexto de NH, asi como las transacciones las
> manejaria en la capa de aplicacion, para no ensuciar el modelo, ya
> que son accidentes tecnologicos. Y no se si usaria un DAO, ya que
> usaria un repositorio.
>
>
> No se que es capa de aplicaci�n.
>
>
> Como dice Jorge el contexto de NH, asi como las transacciones las
> manejaria en la capa de aplicacion, para no ensuciar el modelo, ya
> que son accidentes tecnologicos. Y no se si usaria un DAO, ya que
> usaria un repositorio.
>
>
>
>
>
> Si fuese asi, podrias tener un servicio de aplicacion que tenga
> todo lo relacionado con nhibernate y que llame al repositorio.
>
>
> Jamas. Yo uso nhibernate para el acceso a datos nada m�s. Servicios y
>
>
> Si fuese asi, podrias tener un servicio de aplicacion que tenga
> todo lo relacionado con nhibernate y que llame al repositorio.
>
>
> nhibernate no son palabras compatibles. El �nico lugar donde me
> permito usar nhibernate es en Daos y Repositorios.
>
>
>
> Por otra parte un servicio de dominio para ser un servicio de
> dominio tiene que ser una operacion que no guarde estado, que
> aplique alguna regla del dominio o modifique algo dentro del
> dominio y que no quede natural ponersela a una entidad...
>
>
> Bueno, a mi no me gusta esa definici�n de "servicio de dominio". Por
>
>
>
> Por otra parte un servicio de dominio para ser un servicio de
> dominio tiene que ser una operacion que no guarde estado, que
> aplique alguna regla del dominio o modifique algo dentro del
> dominio y que no quede natural ponersela a una entidad...
>
>
> que no tiene que tener estado?. Me parece que eso esta confundiendo
> "servicio f�sico" con otra cosa. No esta muy bueno tener estado en web
> services o wcf services pero esa es una limitaci�n t�cnica.
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
Pedro Wood
Dec 16, 2009, 9:48:26 AM12/16/09
to altnet-a...@googlegroups.com
Hola,
lo que pasa es que lo único que hace eso es un get por ID + el manejo de transacción.....si no vas a hacer nada más es un pasa manos......
Coincido con que el manejo de transacciones es responsabilidad de la capa de aplicación.
Si vos tenés otro método de capa de aplicación que hace algo, yo directamente tendría el manejo de transacción ahí, llamo al repositorio o DAO para que devuelva el departamento, hago lo que sea que hay que hacer, cierro la transacción, etc...y me ahorro el pasamanos...
Para mi sólo la interfaz del repositorio es parte del dominio, la implementación del repositorio o DAO es parte de la infraestructura, las referencias a NH me quedan sólo en la infraestructura, mi dominio no tiene referencias a ninguna otra capa.
Saludos,
Pedro Wood
Jorge E. Fioranelli
Dec 16, 2009, 9:56:33 AM12/16/09
to altnet-a...@googlegroups.com
Lo que yo hago es hacer que todos los repositorios implementen una interfaz (ej: SomeRepository : ISomeRepository) y desde el dominio uso las interfaces (luego se inyectan con DI).
Los repositorios son "ciudadanos de primera clase" en el dominio, pero están atados a la tecnología de acceso a datos.
El uso de las interfaces te permite abstraerte de ellos y poder mockearlos en los unittests.
Respecto a si conviene un solo repositorio para todo el dominio o hacer uno para cada entidad/aggregate, es mas cuestión de gustos (hay mucha discusión sobre el tema), yo particularmente me inclino por la segunda opción.
Un Abrazo
Jorge
-----Original Message-----
From: altnet-a...@googlegroups.com [mailto:altnet-a...@googlegroups.com] On Behalf Of Raul Lopez
> <mailto:lbo...@gmail.com>> escribió:
> nhibernate no son palabras compatibles. El único lugar donde me
> services o wcf services pero esa es una limitación técnica.
Los repositorios son "ciudadanos de primera clase" en el dominio, pero están atados a la tecnología de acceso a datos.
El uso de las interfaces te permite abstraerte de ellos y poder mockearlos en los unittests.
Respecto a si conviene un solo repositorio para todo el dominio o hacer uno para cada entidad/aggregate, es mas cuestión de gustos (hay mucha discusión sobre el tema), yo particularmente me inclino por la segunda opción.
Un Abrazo
Jorge
-----Original Message-----
From: altnet-a...@googlegroups.com [mailto:altnet-a...@googlegroups.com] On Behalf Of Raul Lopez
Sent: miércoles, 16 de diciembre de 2009 11:44 a.m.
To: altnet-a...@googlegroups.com
Subject: Re: [altnet-argentina] domain o infrastructure?
se complico....
en este momento estaba llegando a la conclusion de que mi codigo si era
un repository....
veo al repository como un concepto de dominio y al dao como algo de
infraestructura, el dao es el que le pega directo al orm o lo que sea y
el repository tiene un nivel de abstraccion mayor
y por lo tanto mas independiente de la tecnologia.
José F. Romaniello escribió:
To: altnet-a...@googlegroups.com
Subject: Re: [altnet-argentina] domain o infrastructure?
se complico....
en este momento estaba llegando a la conclusion de que mi codigo si era
un repository....
veo al repository como un concepto de dominio y al dao como algo de
infraestructura, el dao es el que le pega directo al orm o lo que sea y
el repository tiene un nivel de abstraccion mayor
y por lo tanto mas independiente de la tecnologia.
> <mailto:lbo...@gmail.com>> escribió:
>
> Jose,
>
> En mi opinion ese codigo es tipico de un repositorio, el cual yo
> pongo dentro de la capa de dominio, igual que las factories.
>
>
> Si y no y más o menos. El repositorio o dao para mi es backend, no
> Jose,
>
> En mi opinion ese codigo es tipico de un repositorio, el cual yo
> pongo dentro de la capa de dominio, igual que las factories.
>
>
> siempre lo expongo directamente a mis controllers/presenters. Yo uso
> un servicio por cada caso de uso, si el caso de uso tiene obtener un
> departamento por ID, ahí estará algo así.
> un servicio por cada caso de uso, si el caso de uso tiene obtener un
>
>
>
> Como dice Jorge el contexto de NH, asi como las transacciones las
> manejaria en la capa de aplicacion, para no ensuciar el modelo, ya
> que son accidentes tecnologicos. Y no se si usaria un DAO, ya que
> usaria un repositorio.
>
>
> No se que es capa de aplicación.
>
>
> Como dice Jorge el contexto de NH, asi como las transacciones las
> manejaria en la capa de aplicacion, para no ensuciar el modelo, ya
> que son accidentes tecnologicos. Y no se si usaria un DAO, ya que
> usaria un repositorio.
>
>
>
>
>
> Si fuese asi, podrias tener un servicio de aplicacion que tenga
> todo lo relacionado con nhibernate y que llame al repositorio.
>
>
> Jamas. Yo uso nhibernate para el acceso a datos nada más. Servicios y
>
>
> Si fuese asi, podrias tener un servicio de aplicacion que tenga
> todo lo relacionado con nhibernate y que llame al repositorio.
>
>
> nhibernate no son palabras compatibles. El único lugar donde me
> permito usar nhibernate es en Daos y Repositorios.
>
>
>
> Por otra parte un servicio de dominio para ser un servicio de
> dominio tiene que ser una operacion que no guarde estado, que
> aplique alguna regla del dominio o modifique algo dentro del
> dominio y que no quede natural ponersela a una entidad...
>
>
> Bueno, a mi no me gusta esa definición de "servicio de dominio". Por
>
>
>
> Por otra parte un servicio de dominio para ser un servicio de
> dominio tiene que ser una operacion que no guarde estado, que
> aplique alguna regla del dominio o modifique algo dentro del
> dominio y que no quede natural ponersela a una entidad...
>
>
> que no tiene que tener estado?. Me parece que eso esta confundiendo
> "servicio físico" con otra cosa. No esta muy bueno tener estado en web
> services o wcf services pero esa es una limitación técnica.
> --
> Desuscripción: altnet-argenti...@googlegroups.com
--
Desuscripción: altnet-argenti...@googlegroups.com
> Desuscripción: altnet-argenti...@googlegroups.com
--
Desuscripción: altnet-argenti...@googlegroups.com
Raul Lopez
Dec 16, 2009, 9:53:40 AM12/16/09
to altnet-a...@googlegroups.com
Hola,
en la capa de aplicacion si tenes entonces referencias a NH y a
infraestructura, o sea que directamente el codigo que envie inicialmente
podria residir tal cual lo envie en la capa de aplicacion?
saludos,
Raul.
Pedro Wood escribi�:
> Hola,
>
> lo que pasa es que lo �nico que hace eso es un get por ID + el manejo
> de transacci�n.....si no vas a hacer nada m�s es un pasa manos......
>
> Si vos ten�s otro m�todo de capa de aplicaci�n que hace algo, yo
> directamente tendr�a el manejo de transacci�n ah�, llamo al
> pasamanos...
>
> Para mi s�lo la interfaz del repositorio es parte del dominio, la
> implementaci�n del repositorio o DAO es parte de la infraestructura,
> las referencias a NH me quedan s�lo en la infraestructura, mi dominio
> estas cosas. Con lo cual el c�digo que vos mandaste es mas o
> lio entre "servicio de aplicaci�n" y "servicio de modelo de
> Ser�a algo as�: View -> Presenter (Application Service) ->
en la capa de aplicacion si tenes entonces referencias a NH y a
infraestructura, o sea que directamente el codigo que envie inicialmente
podria residir tal cual lo envie en la capa de aplicacion?
saludos,
Raul.
Pedro Wood escribi�:
> Hola,
>
> lo que pasa es que lo �nico que hace eso es un get por ID + el manejo
> de transacci�n.....si no vas a hacer nada m�s es un pasa manos......
>
> Coincido con que el manejo de transacciones es responsabilidad de la
> capa de aplicaci�n.
> Coincido con que el manejo de transacciones es responsabilidad de la
>
> Si vos ten�s otro m�todo de capa de aplicaci�n que hace algo, yo
> directamente tendr�a el manejo de transacci�n ah�, llamo al
> repositorio o DAO para que devuelva el departamento, hago lo que sea
> que hay que hacer, cierro la transacci�n, etc...y me ahorro el
> pasamanos...
>
> Para mi s�lo la interfaz del repositorio es parte del dominio, la
> implementaci�n del repositorio o DAO es parte de la infraestructura,
> las referencias a NH me quedan s�lo en la infraestructura, mi dominio
> no tiene referencias a ninguna otra capa.
>
>
> Saludos,
>
> Pedro Wood
>
>
> 2009/12/16 Leandro Boffi <lbo...@gmail.com <mailto:lbo...@gmail.com>>
>
>
> Saludos,
>
> Pedro Wood
>
>
>
> Jose,
>
> En mi opinion ese codigo es tipico de un repositorio, el cual yo
> pongo dentro de la capa de dominio, igual que las factories. Como
> dice Jorge el contexto de NH, asi como las transacciones las
> manejaria en la capa de aplicacion, para no ensuciar el modelo, ya
> que son accidentes tecnologicos. Y no se si usaria un DAO, ya que
> usaria un repositorio.
>
> Si fuese asi, podrias tener un servicio de aplicacion que tenga
> todo lo relacionado con nhibernate y que llame al repositorio.
>
> Por otra parte un servicio de dominio para ser un servicio de
> dominio tiene que ser una operacion que no guarde estado, que
> aplique alguna regla del dominio o modifique algo dentro del
> dominio y que no quede natural ponersela a una entidad...
>
>
>
>
> Jose,
>
> En mi opinion ese codigo es tipico de un repositorio, el cual yo
> pongo dentro de la capa de dominio, igual que las factories. Como
> dice Jorge el contexto de NH, asi como las transacciones las
> manejaria en la capa de aplicacion, para no ensuciar el modelo, ya
> que son accidentes tecnologicos. Y no se si usaria un DAO, ya que
> usaria un repositorio.
>
> Si fuese asi, podrias tener un servicio de aplicacion que tenga
> todo lo relacionado con nhibernate y que llame al repositorio.
>
> Por otra parte un servicio de dominio para ser un servicio de
> dominio tiene que ser una operacion que no guarde estado, que
> aplique alguna regla del dominio o modifique algo dentro del
> dominio y que no quede natural ponersela a una entidad...
>
>
>
>
> 2009/12/16 Jos� F. Romaniello <jfroma...@gmail.com
> <mailto:jfroma...@gmail.com>>
>
> En web se utiliza mucho por request, como dijo Jorge, aunque
> tambi�n como dijo Jorge a veces es necesario algo mas granular.
> En web se utiliza mucho por request, como dijo Jorge, aunque
>
> En winforms no hay algo como el request para demarcar cuando
> inicia o no una transacci�n, en realidad yo utilizo AOP para
> En winforms no hay algo como el request para demarcar cuando
> estas cosas. Con lo cual el c�digo que vos mandaste es mas o
> menos equivalente a esto:
>
> [PersistenceConversational]
> public class ServicioNoSeQue{
>
> private IDaoFactory _daoFactory;
>
> public ServicioNoSeQue(IDaoFactory daoFactory){
> _daoFactory = daoFactory;
> }
>
> [PersistenceConversation]
> public Departamento ObtenerDepartamento(int id){
> return _daoFactory.GetDaoOf<Departamento>().GetById(id);
> }
> }
>
> Si este es tu caso, te aconsejo mirar los posts de Fabio al
> respecto, sobre todo este:
> http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html
>
> Otra cosa, despu�s de leer lo que dice Carlos Peix, se me hizo
>
> [PersistenceConversational]
> public class ServicioNoSeQue{
>
> private IDaoFactory _daoFactory;
>
> public ServicioNoSeQue(IDaoFactory daoFactory){
> _daoFactory = daoFactory;
> }
>
> [PersistenceConversation]
> public Departamento ObtenerDepartamento(int id){
> return _daoFactory.GetDaoOf<Departamento>().GetById(id);
> }
> }
>
> Si este es tu caso, te aconsejo mirar los posts de Fabio al
> respecto, sobre todo este:
> http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html
>
> lio entre "servicio de aplicaci�n" y "servicio de modelo de
> dominio".
>
> Este metodo es consumido por un servicio de mas alto nivel
> (normalmente en Application), que hace algo con el
> resultado, lo pasa a Presentation, etc .... y tal como
> esta planteado funciona.
>
>
> Me parece que lo que vos estas llamando como "Servicio de
> aplicaci�n" es un presenter o controller. Puede ser?
>
> Este metodo es consumido por un servicio de mas alto nivel
> (normalmente en Application), que hace algo con el
> resultado, lo pasa a Presentation, etc .... y tal como
> esta planteado funciona.
>
>
> Me parece que lo que vos estas llamando como "Servicio de
> Ser�a algo as�: View -> Presenter (Application Service) ->
> Domain Service -> Dao ??
> --
> --
Leandro Boffi
Dec 16, 2009, 9:58:46 AM12/16/09
to altnet-a...@googlegroups.com
José,
Si usamos DDD, con la arquitectura tipica, tenemos una capa de dominio limpia, ocupada de expresar el dominio, y tenemos una capa de aplicacion responsable de los accidentes tecnologicos como WebServices, Transacciones, etc, ahi es donde tendrias los famosos Servicios de aplicacion que podrian ser uno por pantalla...
Pero en la capa de dominio tenes que tener Entities, Value Objects, Services. Estos Services son los que tienen que ser sin estado. Ya que si es algo que tiene estado debe ser o una Entidad, o un Value Object.
En cuanto al repositorio, esta bueno usar dao si no queres que la implementacion del repositorio te quede atada a una tecnologia, yo en la practica no suelo usar DAOs ya que son una capa mas y no lo veo super necesario, pero no lo veo mal.
Para testear lo que hago es que el repositorio implemente una interfaz y asi poder mockearlo, y para testear el repositorio lo que hago es mockear el datacontext.
2009/12/16 José F. Romaniello <jfroma...@gmail.com>
--
Desuscripción: altnet-argenti...@googlegroups.com
Carlos Peix
Dec 16, 2009, 10:18:15 AM12/16/09
to altnet-argentina
2009/12/16 Raul Lopez <rlope...@gmail.com>
veo al repository como un concepto de dominio y al dao como algo de
infraestructura
Los repositorios generan confusiones, a mi juicio, porque viven en dos mundos. Son a) un concepto del dominio con b) una implementacion de infraestructura. Las interfaces que definen a los repositorios "viven" en el dominio pero las implementaciones viven en infraestructura (o en las pruebas en caso de que se implementen repositorios en memoria para los tests).
----------------------------------
Carlos Peix
Carlos Peix
José F. Romaniello
Dec 16, 2009, 10:24:07 AM12/16/09
to altnet-a...@googlegroups.com
La gran diferencia entre Dao y Repository esta en la interface. Según Martin Fawler http://martinfowler.com/eaaCatalog/repository.html
A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection.
Por lo tanto una interface valida para IRepository es esta:
|
public interface IRepository<T> : IQueryable<T> |
|
{ |
|
T Get(object id); |
|
T Load(object id); |
|
T MakePersistent(T entity); |
|
void Refresh(T entity); |
|
void MakeTransient(T entity); |
|
}
Extraido de mi ejemplo "Chinook Media Manager", implementaciones aquí: http://code.google.com/p/unhaddins/source/browse/trunk/Examples/uNHAddIns.Examples.WPF/ChinookMediaManager.Data.Impl/Repositories/Repository.cs Mientras que un dao luce así: public interface IDao <T>{ IList<T> FindBy(Criterio...) T Get(object id) MakePersistent() } public interface IDaoCustomer : IDao<Customer>{ IList<T> GetCustomersWith...Blabla() } De esto ultimo se desprende que el 95% de la gente que asegura estar usando repository, esta usando DAO. Este tema ya se discutió en otras listas de correo y blogposts. Existen una variante de Dao que es utilizando un mecanismo de "Especificación" Ver, Fabio Maulo Capítulo 1, Versículo 10, y dijo el tano a sus apostoles: http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-dao.html |
Carlos Peix
Dec 16, 2009, 10:33:53 AM12/16/09
to altnet-argentina
A estas alturas es confuso decir, simplemente, servicios. Por ejemplo yo identifico los siguientes tipos de servicios:
Servicio (de Aplicacion): tambien llamados fachadas, usualmente proveen una API o protocolo de acceso a la aplicacion al tiempo que aseguran la integridad de la misma asegurando algunos "cross cutting concerns", por ejemplo transacciones, seguridad, etc.
Servicio (de Dominio): en el contexto de DDD, algunos los definen como los objetos que representan conceptos que no se ajustan a las entidades o los value objetcs. Usualmente no son persistentes (nunca me cruce con un servicio de dominio que tenga estado persistente).
Servicio (de Infraestructura): Son servicios que las demas capas (Aplicacion y Modelo de Dominio) utilizan siempre referenciando . Por ejemplo los repositorios, servicios de envio de mail, servicios de acceso a archivows, etc.
Pedro Wood
Dec 16, 2009, 10:37:35 AM12/16/09
to altnet-a...@googlegroups.com
Si, podría residir en la capa de aplicación, aunque como te decía antes si lo único que va a hacer es traer un departamento por ID entonces por qué no usar directamente el repositorio y listo ?
Saludos,
Pedro Wood
2009/12/16 Raul Lopez <rlope...@gmail.com>
Hola,
en la capa de aplicacion si tenes entonces referencias a NH y a
infraestructura, o sea que directamente el codigo que envie inicialmente
podria residir tal cual lo envie en la capa de aplicacion?
saludos,
Raul.
Pedro Wood escribió:
> Hola,
>
> lo que pasa es que lo único que hace eso es un get por ID + el manejo
> de transacción.....si no vas a hacer nada más es un pasa manos......
>
> Coincido con que el manejo de transacciones es responsabilidad de la
> capa de aplicación.
>
> Si vos tenés otro método de capa de aplicación que hace algo, yo
> directamente tendría el manejo de transacción ahí, llamo al
> repositorio o DAO para que devuelva el departamento, hago lo que sea
> que hay que hacer, cierro la transacción, etc...y me ahorro el
> pasamanos...
>
> Para mi sólo la interfaz del repositorio es parte del dominio, la
> implementación del repositorio o DAO es parte de la infraestructura,
> las referencias a NH me quedan sólo en la infraestructura, mi dominio
> no tiene referencias a ninguna otra capa.
>
>
> Saludos,
>
> Pedro Wood
>
>
> 2009/12/16 Leandro Boffi <lbo...@gmail.com <mailto:lbo...@gmail.com>>
>
> Jose,
>
> En mi opinion ese codigo es tipico de un repositorio, el cual yo
> pongo dentro de la capa de dominio, igual que las factories. Como
> dice Jorge el contexto de NH, asi como las transacciones las
> manejaria en la capa de aplicacion, para no ensuciar el modelo, ya
> que son accidentes tecnologicos. Y no se si usaria un DAO, ya que
> usaria un repositorio.
>
> Si fuese asi, podrias tener un servicio de aplicacion que tenga
> todo lo relacionado con nhibernate y que llame al repositorio.
>
> Por otra parte un servicio de dominio para ser un servicio de
> dominio tiene que ser una operacion que no guarde estado, que
> aplique alguna regla del dominio o modifique algo dentro del
> dominio y que no quede natural ponersela a una entidad...
>
>
>
>
> 2009/12/16 José F. Romaniello <jfroma...@gmail.com> <mailto:jfroma...@gmail.com>>
>
> En web se utiliza mucho por request, como dijo Jorge, aunque
> también como dijo Jorge a veces es necesario algo mas granular.
>
> En winforms no hay algo como el request para demarcar cuando
> inicia o no una transacción, en realidad yo utilizo AOP para
> estas cosas. Con lo cual el código que vos mandaste es mas o
> menos equivalente a esto:
>
> [PersistenceConversational]
> public class ServicioNoSeQue{
>
> private IDaoFactory _daoFactory;
>
> public ServicioNoSeQue(IDaoFactory daoFactory){
> _daoFactory = daoFactory;
> }
>
> [PersistenceConversation]
> public Departamento ObtenerDepartamento(int id){
> return _daoFactory.GetDaoOf<Departamento>().GetById(id);
> }
> }
>
> Si este es tu caso, te aconsejo mirar los posts de Fabio al
> respecto, sobre todo este:
> http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html
>
> Otra cosa, después de leer lo que dice Carlos Peix, se me hizo
> lio entre "servicio de aplicación" y "servicio de modelo de
> dominio".
>
> Este metodo es consumido por un servicio de mas alto nivel
> (normalmente en Application), que hace algo con el
> resultado, lo pasa a Presentation, etc .... y tal como
> esta planteado funciona.
>
>
> Me parece que lo que vos estas llamando como "Servicio de
> aplicación" es un presenter o controller. Puede ser?
> Sería algo así: View -> Presenter (Application Service) ->
> Domain Service -> Dao ??
> --
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>> Desuscripción: altnet-argenti...@googlegroups.com
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>
Jorge E. Fioranelli
Dec 16, 2009, 10:45:12 AM12/16/09
to altnet-a...@googlegroups.com
José,
Si bien Fowler separa entre el patrón Repository y el de Data Mapper (o como vos bien decís, DAO), para los hechos de DDD ambos son “Repositories”.
Evans en su libro se tomó la libertad de englobar los dos mecanismos dentro del mismo patrón.
Copio la cita del libro:
…All repositories provide methods that allow a client to request objects matching some criteria, but there is a range of options of how to design this interface.
The easiest REPOSITORY to build has hard-coded queries with specific parameters. These queries can be various: retrieving an ENTITY by its identity (provided by almost all REPOSITORIES); requesting a collection of objects with a particular attribute value or a complex combination of parameters; selecting objects based on value ranges (such as date ranges); and even performing some calculations that fall within the general responsibility of a REPOSITORY (especially drawing on operations supported by the underlying database)…
…Hard-coded queries can be built on top of any infrastructure and without a lot of investment, because they do just what some client would have had to do anyway.
On projects with a lot of querying, a REPOSITORY framework can be built that allows more flexible queries. This calls for a staff familiar with the necessary technology and is greatly aided by a supportive infrastructure.
One particularly apt approach to generalizing REPOSITORIES through a framework is to use SPECIFICATION-based queries. A SPECIFICATION allows a client to describe (that is, specify) what it wants without concern for how it will be obtained. In the process, an object that can actually carry out the selection is created...
Un Abrazo
Jorge
From: altnet-a...@googlegroups.com
[mailto:altnet-a...@googlegroups.com] On Behalf Of José F.
Romaniello
Sent: miércoles, 16 de diciembre de 2009 12:24 p.m.
To: altnet-a...@googlegroups.com
Subject: Re: [altnet-argentina] domain o infrastructure?
La gran diferencia entre Dao y Repository esta en la interface. Según Martin Fawler http://martinfowler.com/eaaCatalog/repository.html
Raul Lopez
Dec 16, 2009, 11:45:44 AM12/16/09
to altnet-a...@googlegroups.com
Pedro Wood escribi�:
> Si, podr�a residir en la capa de aplicaci�n, aunque como te dec�a
> antes si lo �nico que va a hacer es traer un departamento por ID
> entonces por qu� no usar directamente el repositorio y listo ?
De acuerdo, podes evitar el pasamano.
>
> Pero si, en la capa de aplicaci�n no tengo ning�n problema en tener
sesiones/transacciones en Application.
Saludos,
Raul.
> <mailto:rlope...@gmail.com>>
> > Hola,
> >
> > lo que pasa es que lo �nico que hace eso es un get por ID + el
> manejo
> > de transacci�n.....si no vas a hacer nada m�s es un pasa manos......
> > pasamanos...
> >
> > Para mi s�lo la interfaz del repositorio es parte del dominio, la
> > implementaci�n del repositorio o DAO es parte de la infraestructura,
> > las referencias a NH me quedan s�lo en la infraestructura, mi
> <mailto:jfroma...@gmail.com>
> > <mailto:jfroma...@gmail.com <mailto:jfroma...@gmail.com>>>
> > estas cosas. Con lo cual el c�digo que vos mandaste es mas o
> me hizo
> > lio entre "servicio de aplicaci�n" y "servicio de modelo de
> > Ser�a algo as�: View -> Presenter (Application Service) ->
> <mailto:altnet-argentina%252Buns...@googlegroups.com>>
> <mailto:altnet-argentina%252Buns...@googlegroups.com>>
> Si, podr�a residir en la capa de aplicaci�n, aunque como te dec�a
> antes si lo �nico que va a hacer es traer un departamento por ID
> entonces por qu� no usar directamente el repositorio y listo ?
De acuerdo, podes evitar el pasamano.
>
> Pero si, en la capa de aplicaci�n no tengo ning�n problema en tener
> referencias a la infraestructura, a NH no tengo porque inyecto las
> implementaciones de los repositorios.
No me queda claro como evitar referenciar a NH para manejar las
> implementaciones de los repositorios.
sesiones/transacciones en Application.
Saludos,
Raul.
> <mailto:rlope...@gmail.com>>
>
> Hola,
>
> en la capa de aplicacion si tenes entonces referencias a NH y a
> infraestructura, o sea que directamente el codigo que envie
> inicialmente
> podria residir tal cual lo envie en la capa de aplicacion?
>
> saludos,
> Raul.
>
> Pedro Wood escribi�:
> Hola,
>
> en la capa de aplicacion si tenes entonces referencias a NH y a
> infraestructura, o sea que directamente el codigo que envie
> inicialmente
> podria residir tal cual lo envie en la capa de aplicacion?
>
> saludos,
> Raul.
>
> > Hola,
> >
> > lo que pasa es que lo �nico que hace eso es un get por ID + el
> manejo
> > de transacci�n.....si no vas a hacer nada m�s es un pasa manos......
> >
> > Coincido con que el manejo de transacciones es responsabilidad de la
> > Coincido con que el manejo de transacciones es responsabilidad de la
> > capa de aplicaci�n.
> >
> > Si vos ten�s otro m�todo de capa de aplicaci�n que hace algo, yo
> > directamente tendr�a el manejo de transacci�n ah�, llamo al
> >
> > Si vos ten�s otro m�todo de capa de aplicaci�n que hace algo, yo
> > repositorio o DAO para que devuelva el departamento, hago lo que sea
> > que hay que hacer, cierro la transacci�n, etc...y me ahorro el
> > pasamanos...
> >
> > Para mi s�lo la interfaz del repositorio es parte del dominio, la
> > implementaci�n del repositorio o DAO es parte de la infraestructura,
> > las referencias a NH me quedan s�lo en la infraestructura, mi
> dominio
> > no tiene referencias a ninguna otra capa.
> >
> >
> > Saludos,
> >
> > Pedro Wood
> >
> >
> > 2009/12/16 Leandro Boffi <lbo...@gmail.com
> <mailto:lbo...@gmail.com> <mailto:lbo...@gmail.com
> > no tiene referencias a ninguna otra capa.
> >
> >
> > Saludos,
> >
> > Pedro Wood
> >
> >
> > 2009/12/16 Leandro Boffi <lbo...@gmail.com
> <mailto:lbo...@gmail.com>>>
> >
> > Jose,
> >
> > En mi opinion ese codigo es tipico de un repositorio, el cual yo
> > pongo dentro de la capa de dominio, igual que las factories.
> Como
> > dice Jorge el contexto de NH, asi como las transacciones las
> > manejaria en la capa de aplicacion, para no ensuciar el
> modelo, ya
> > que son accidentes tecnologicos. Y no se si usaria un DAO,
> ya que
> > usaria un repositorio.
> >
> > Si fuese asi, podrias tener un servicio de aplicacion que tenga
> > todo lo relacionado con nhibernate y que llame al repositorio.
> >
> > Por otra parte un servicio de dominio para ser un servicio de
> > dominio tiene que ser una operacion que no guarde estado, que
> > aplique alguna regla del dominio o modifique algo dentro del
> > dominio y que no quede natural ponersela a una entidad...
> >
> >
> >
> >
> > 2009/12/16 Jos� F. Romaniello <jfroma...@gmail.com
> >
> > Jose,
> >
> > En mi opinion ese codigo es tipico de un repositorio, el cual yo
> > pongo dentro de la capa de dominio, igual que las factories.
> Como
> > dice Jorge el contexto de NH, asi como las transacciones las
> > manejaria en la capa de aplicacion, para no ensuciar el
> modelo, ya
> > que son accidentes tecnologicos. Y no se si usaria un DAO,
> ya que
> > usaria un repositorio.
> >
> > Si fuese asi, podrias tener un servicio de aplicacion que tenga
> > todo lo relacionado con nhibernate y que llame al repositorio.
> >
> > Por otra parte un servicio de dominio para ser un servicio de
> > dominio tiene que ser una operacion que no guarde estado, que
> > aplique alguna regla del dominio o modifique algo dentro del
> > dominio y que no quede natural ponersela a una entidad...
> >
> >
> >
> >
> <mailto:jfroma...@gmail.com>
> > <mailto:jfroma...@gmail.com <mailto:jfroma...@gmail.com>>>
> >
> > En web se utiliza mucho por request, como dijo Jorge, aunque
> > tambi�n como dijo Jorge a veces es necesario algo mas
> > En web se utiliza mucho por request, como dijo Jorge, aunque
> granular.
> >
> > En winforms no hay algo como el request para demarcar cuando
> > inicia o no una transacci�n, en realidad yo utilizo AOP para
> >
> > En winforms no hay algo como el request para demarcar cuando
> > estas cosas. Con lo cual el c�digo que vos mandaste es mas o
> > menos equivalente a esto:
> >
> > [PersistenceConversational]
> > public class ServicioNoSeQue{
> >
> > private IDaoFactory _daoFactory;
> >
> > public ServicioNoSeQue(IDaoFactory daoFactory){
> > _daoFactory = daoFactory;
> > }
> >
> > [PersistenceConversation]
> > public Departamento ObtenerDepartamento(int id){
> > return _daoFactory.GetDaoOf<Departamento>().GetById(id);
> > }
> > }
> >
> > Si este es tu caso, te aconsejo mirar los posts de Fabio al
> > respecto, sobre todo este:
> >
> http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html
> >
> > Otra cosa, despu�s de leer lo que dice Carlos Peix, se
> >
> > [PersistenceConversational]
> > public class ServicioNoSeQue{
> >
> > private IDaoFactory _daoFactory;
> >
> > public ServicioNoSeQue(IDaoFactory daoFactory){
> > _daoFactory = daoFactory;
> > }
> >
> > [PersistenceConversation]
> > public Departamento ObtenerDepartamento(int id){
> > return _daoFactory.GetDaoOf<Departamento>().GetById(id);
> > }
> > }
> >
> > Si este es tu caso, te aconsejo mirar los posts de Fabio al
> > respecto, sobre todo este:
> >
> http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html
> >
> me hizo
> > lio entre "servicio de aplicaci�n" y "servicio de modelo de
> > dominio".
> >
> > Este metodo es consumido por un servicio de mas alto
> nivel
> > (normalmente en Application), que hace algo con el
> > resultado, lo pasa a Presentation, etc .... y tal como
> > esta planteado funciona.
> >
> >
> > Me parece que lo que vos estas llamando como "Servicio de
> > aplicaci�n" es un presenter o controller. Puede ser?
> >
> > Este metodo es consumido por un servicio de mas alto
> nivel
> > (normalmente en Application), que hace algo con el
> > resultado, lo pasa a Presentation, etc .... y tal como
> > esta planteado funciona.
> >
> >
> > Me parece que lo que vos estas llamando como "Servicio de
> > Ser�a algo as�: View -> Presenter (Application Service) ->
> > Domain Service -> Dao ??
> > --
> > --
> > Desuscripci�n:
> altnet-argenti...@googlegroups.com
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>
> > <mailto:altnet-argentina%2Bunsu...@googlegroups.com
> altnet-argenti...@googlegroups.com
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>
> <mailto:altnet-argentina%252Buns...@googlegroups.com>>
> >
> >
> > --
> > Desuscripci�n: altnet-argenti...@googlegroups.com
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>
> > <mailto:altnet-argentina%2Bunsu...@googlegroups.com
> >
> > --
> > Desuscripci�n: altnet-argenti...@googlegroups.com
> <mailto:altnet-argentina%2Bunsu...@googlegroups.com>
> <mailto:altnet-argentina%252Buns...@googlegroups.com>>
José F. Romaniello
Dec 16, 2009, 1:41:24 PM12/16/09
to altnet-a...@googlegroups.com
No me queda claro como evitar referenciar a NH para manejar las
sesiones/transacciones en Application.
Esa es la magia de unhaddins y CpBT. Yo termino marcando mis servicios como te mostré un par de mails atrás, pero esos atributos no tiene bajo ningún punto de vista referencia o relación con nhibernate.
El día de mañana puede haber una implementación de CpBT para entity framework o para otra cosa.
Aca hay ejemplos para wpf, winforms, asp.net mvc y monorail.
Raul Lopez
Dec 16, 2009, 3:00:15 PM12/16/09
to altnet-a...@googlegroups.com
Gracias Jose, ya lo estoy mirando
Abrazo,
Raul
Jos� F. Romaniello escribi�:
> bajo ning�n punto de vista referencia o relaci�n con nhibernate.
>
> El d�a de ma�ana puede haber una implementaci�n de CpBT para entity
> monorail.
> http://code.google.com/p/unhaddins/source/browse/#svn/trunk/Examples
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
Abrazo,
Raul
Jos� F. Romaniello escribi�:
>
> No me queda claro como evitar referenciar a NH para manejar las
>
> sesiones/transacciones en Application.
>
>
> Esa es la magia de unhaddins y CpBT. Yo termino marcando mis servicios
> como te mostr� un par de mails atr�s, pero esos atributos no tiene
> No me queda claro como evitar referenciar a NH para manejar las
>
> sesiones/transacciones en Application.
>
>
> Esa es la magia de unhaddins y CpBT. Yo termino marcando mis servicios
> bajo ning�n punto de vista referencia o relaci�n con nhibernate.
>
> El d�a de ma�ana puede haber una implementaci�n de CpBT para entity
> framework o para otra cosa.
>
> Aca hay ejemplos para wpf, winforms, asp.net <http://asp.net> mvc y
>
> monorail.
> http://code.google.com/p/unhaddins/source/browse/#svn/trunk/Examples
> --
> Desuscripci�n: altnet-argenti...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages