Unit of Work & application layers
24 views
Skip to first unread message
gavin.schultz
Mar 17, 2009, 10:36:59 AM3/17/09
to nhusers
I've read an awful lot about unit-of-work and sessions and so on, and
watched Ayende's excellent webcast about App Architecture, but I'm
still getting confused. There seem to be conflicting pieces of advice.
For instance it is said (paraphrasing here):
* NHibernate allows you to design your business entities & services so
that they have no knowledge of NHibernate or sessions; in other words,
they are not coupled at all with the way in which the data is
persisted.
That sounds just wonderful, but then I read:
* DO NOT open a new session for each of your repositories, or for each
of the calls within the repository. Instead use a context-based
session outside the repository. Such as the Unit Of Work e.g. the one
in Rhino Commons.
And that sounds perfectly fine too, because hey, ideally I'd like to
work on my objects without opening new sessions all the time, and give
the ability to do transactions across different repositories, and so
on.
But hang on, doesn't that mean that we're putting the Unit Of Work
classes up in the business entities and services? And doesn't that
mean that we're coupling the business layer to the persistence layer
in the end? In particular aren't we coupling the business layer to
NHibernate (since it seems everywhere we talk about Unit Of Work, we
really mean an NHibernate session wrapper)? Or do we not consider the
Unit Of Work to be part of that layer, do we think of it as some kind
of business abstraction?
We all seem very strict about setting the boundaries between what the
different layers can access, but I'm unclear about where the Unit Of
Work fits into those layers - does it basically cross-cut everything?
Sincerely confused and grateful for any advice,
Gavin
watched Ayende's excellent webcast about App Architecture, but I'm
still getting confused. There seem to be conflicting pieces of advice.
For instance it is said (paraphrasing here):
* NHibernate allows you to design your business entities & services so
that they have no knowledge of NHibernate or sessions; in other words,
they are not coupled at all with the way in which the data is
persisted.
That sounds just wonderful, but then I read:
* DO NOT open a new session for each of your repositories, or for each
of the calls within the repository. Instead use a context-based
session outside the repository. Such as the Unit Of Work e.g. the one
in Rhino Commons.
And that sounds perfectly fine too, because hey, ideally I'd like to
work on my objects without opening new sessions all the time, and give
the ability to do transactions across different repositories, and so
on.
But hang on, doesn't that mean that we're putting the Unit Of Work
classes up in the business entities and services? And doesn't that
mean that we're coupling the business layer to the persistence layer
in the end? In particular aren't we coupling the business layer to
NHibernate (since it seems everywhere we talk about Unit Of Work, we
really mean an NHibernate session wrapper)? Or do we not consider the
Unit Of Work to be part of that layer, do we think of it as some kind
of business abstraction?
We all seem very strict about setting the boundaries between what the
different layers can access, but I'm unclear about where the Unit Of
Work fits into those layers - does it basically cross-cut everything?
Sincerely confused and grateful for any advice,
Gavin
Fabio Maulo
Mar 17, 2009, 10:45:43 AM3/17/09
to nhu...@googlegroups.com
Probably the definition of the pattern will help you
--
Fabio Maulo
"A Unit of Work keeps track of everything you do during a business transaction that can affect the database."
--
Fabio Maulo
Fabio Maulo
Mar 17, 2009, 10:50:54 AM3/17/09
to nhu...@googlegroups.com
ah... and the trick is the abstraction of UoW because you can implements UoW including using pure ADO.NET (if you are using NH the UoW is the nh-session itself).
--
Fabio Maulo
I don't know if it can help you but...
--
Fabio Maulo
gavin.schultz
Mar 17, 2009, 6:30:33 PM3/17/09
to nhusers
Thanks Fabio! Everything I've read about UoW is suddenly starting to
make more sense. I can't wait for the day when all of this becomes
second-nature to me.
- Gavin
On Mar 18, 12:50 am, Fabio Maulo <fabioma...@gmail.com> wrote:
> ah... and the trick is the abstraction of UoW because you can implements UoW
> including using pure ADO.NET (if you are using NH the UoW is the nh-session
> itself).
> I don't know if it can help you but...http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html
>
> 2009/3/17 Fabio Maulo <fabioma...@gmail.com>
make more sense. I can't wait for the day when all of this becomes
second-nature to me.
- Gavin
On Mar 18, 12:50 am, Fabio Maulo <fabioma...@gmail.com> wrote:
> ah... and the trick is the abstraction of UoW because you can implements UoW
> including using pure ADO.NET (if you are using NH the UoW is the nh-session
> itself).
> I don't know if it can help you but...http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html
>
>
>
>
> > Probably the definition of the pattern will help you"A Unit of Work keeps
> > track of everything you do during a business transaction that can affect
> > the database."http://martinfowler.com/eaaCatalog/unitOfWork.html
>
> > Note : business transaction
>
> > 2009/3/17 gavin.schultz <gavin.schu...@spectraqest.com.au>
>
>
> > Probably the definition of the pattern will help you"A Unit of Work keeps
> > track of everything you do during a business transaction that can affect
> > the database."http://martinfowler.com/eaaCatalog/unitOfWork.html
>
> > Note : business transaction
>
kello
Mar 18, 2009, 7:47:51 PM3/18/09
to nhusers
I struggled a bit with these questions too and to keep the UoW out of
the domain layer I implemented it this way:
1. A class in the UI or Appliction Layer creates a UoW object (NH
session wrapper) which is implemented in the Infrastructure Layer.
This UoW object is put into the executing thread's local storage
(using e.g. CallContext if it is a WinForms/WPF app).
2. The class in the UI layer is injected with a repository object
through IoC container.
3. The repository's interace is defined in the Domain Layer but it is
implemented by a class in the Infrastructure Layer.
4. The repository implementation (in the Infrastructure Layer) reads
the active UoW from the thread's local storage, get's the NH session
from it and then goes on the make e.g. a criteria query.
5. Objects inside the Domain Layer that uses repositories are only
aware of the repositories' interfaces and are injected with the
Infrastructure Layer's implementation through IoC container.
This way the domain layer has no knowlegde of the UoW but the UI/
Application and Infrastructure layers do. Now this is just the way I
did it, I don't claim it is any good ;-)
/Jonas
On Mar 17, 3:36 pm, "gavin.schultz" <gavin.schu...@spectraqest.com.au>
wrote:
the domain layer I implemented it this way:
1. A class in the UI or Appliction Layer creates a UoW object (NH
session wrapper) which is implemented in the Infrastructure Layer.
This UoW object is put into the executing thread's local storage
(using e.g. CallContext if it is a WinForms/WPF app).
2. The class in the UI layer is injected with a repository object
through IoC container.
3. The repository's interace is defined in the Domain Layer but it is
implemented by a class in the Infrastructure Layer.
4. The repository implementation (in the Infrastructure Layer) reads
the active UoW from the thread's local storage, get's the NH session
from it and then goes on the make e.g. a criteria query.
5. Objects inside the Domain Layer that uses repositories are only
aware of the repositories' interfaces and are injected with the
Infrastructure Layer's implementation through IoC container.
This way the domain layer has no knowlegde of the UoW but the UI/
Application and Infrastructure layers do. Now this is just the way I
did it, I don't claim it is any good ;-)
/Jonas
On Mar 17, 3:36 pm, "gavin.schultz" <gavin.schu...@spectraqest.com.au>
wrote:
Reply all
Reply to author
Forward
0 new messages