yes.
the Impl will take car of actual UnitOfWork implementations.
On Tue, Oct 21, 2008 at 12:52 AM, Nick72 <[EMAIL PROTECTED]> wrote:
>
> Regarding the onion architecture, I think I'm using it. Is it just an
> implementation of the Separated Interface pattern? I.e. define the
> repositories in the data layer and the interfaces in the domain, then
> use IOC container to plug the dependencies in?
>
> When you say keep track of transactions on your AbstractRepository,
> does this imply that Controllers/MessageHandlers have a dependency on
> the layer in which the AbstractRespository is defined?
> If one adheres to DDD where transactions are controlled in the
> application services layer as well as adhering to the Onion
> Architecture where the application layer doesn't depend on the
> infrastructure layer, should one then define an IUnitOfWork in the
> application services layer?
>
>
> On Oct 20, 6:06 pm, "Ken Egozi" <[EMAIL PROTECTED]> wrote:
> > 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/bloghttp://www.musicglue.comhttp://www.castleproject.orghttp://www.gotfriends.co.il
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
