ATM and Microsoft's new ASP.Net don't play nicely when you get
parameter binders involved, so I've added something to MvcContrib for
this as well.
Still being evaluated here:
http://www.codeplex.com/MVCContrib/SourceControl/PatchList.aspx
On Mon, Oct 20, 2008 at 3: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/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
-~----------~----~----~----~------~----~------~--~---
