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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
