As far as DDD goes, I'd strongly recommend you take a look at "Onion
Architecture" - a relatively new term for well known best practices.
I short - your domain libraries will know nothing of UoW, or even NH at
that.
you would have stuff like
namespace My.Cool.Domain
{
interface IUserRepo
{
void Save(User u);
IEnumerable<User> FindBy(UsersFilter filter);
}
}
using IoC tools you'd supply your running application with implementations,
like:
namespace My.Cool.Domain.Impl
{
public class UserRepo : IUserRepo, AbstractRepo
{
public void Save(user u)
{
session.Save(u);
}
public IEnumerable<User> FindBy(UsersFilter filter)
{
return new UsersCriteria(filter).GetExecutableCriteria(session)
.List<User>();
}
}
}
As for handling transactions - imo this is not a domain concern (not even
domain impl. concern), but rather a ServiceLayer concern.
So, I think that the best place to discuss transaction is in Controllers or
in MessageHandlers, wrapping all domain calls with a transaction.
It can be achieved using thinks like AutomaticTransacionsFacility of Castle,
or by keeping track of openned current transaciton manually, say on your
AbstractRepository class
On Mon, Oct 20, 2008 at 11:06 PM, Nick72 <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've read the Gabriel Schenker's blog posts on the Unit of Work
> pattern for NHib and have a few questions.
>
> 1. In some repository implementations I see:
>
> public void Add(Entity entity)
> {
> using (var session = GetSession())
> using (var transaction =
> session.BeginTransaction())
> {
> GetSession().Save(entity);
> transaction.Commit();
> }
> }
>
> Now if I open a transaction in my unit of work in some higher layer,
> when a transaction is created in the repository, will it be a child
> transaction of the previously created one? That is to say, I may want
> to do somewhere higher up in my code:
>
> transaction.BeginTransaction()
> customerRepository.Add(customer);
> orderRepository.Add(order);
> transaction.Commit()
>
> I want to make sure that if there is an error saving the order to the
> DB, the customer changes will get rolled back. Is this the case?
>
> 2. How do people usually reference the Unit of Work in a DDD scenario.
> I have defined the Unit of Work in my data layer, but don't want my
> domain or service layer with a dependency on my data layer. For
> repositories I define their interfaces in the Domain. Would you
> recommend a similar approach for the Unit of Work? A Unit of Work
> doesn't really seem a domain concept to me, but I'm not sure where
> else to put it if I don't want a dependency on my Data layer. (Sorry
> if this isn't specifically NHib talk and is more DDD.)
>
> Thanks for feedback.
> >
>
--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.musicglue.com
http://www.castleproject.org
http://www.gotfriends.co.il
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
