I'm using WebForm, the page can't be resovled from Container( or I
don't know how to do that). So I must place the [Transactional]
attribute on my Service Layer. I have some IRepository classes, too.
They handle data asscess operations, such as Create, Delete, Find,
etc. And my question is, should I also place the trasaction on these
repositories (because I may call the repositories on UI, or other
layer directly) ?  Or should my service layer wrap all the operations
of repositories, and just place the transactions on the service layer?

Which solution is better? The transaction boundary is not very clear
in the first one, but there are many extra codes in the second one.

On Tue, Oct 21, 2008 at 2:48 PM, Gabriel Schenker <[EMAIL PROTECTED]> wrote:
> As a sample I have something like this in my Monorail (MVC) application
>
> [ Transactional ]
> public class ProductController : SomeBaseController
> {
>   [ Transaction ]
>   public virtual void DoSomeStuffNeedingATransaction(...)
>   {...}
> }
>
>
> On Tue, Oct 21, 2008 at 8:47 AM, Gabriel Schenker <[EMAIL PROTECTED]>
> wrote:
>>
>> In my Monorail based applications a unit of work is started when a (web-)
>> request starts and the UoW is committed when the request finishes. The
>> boundary of my transactions is defined by the application service layer. I
>> use ATM.
>> Inside a single transaction I can have many database operations. If one of
>> those operations fails, the whole transaction fails and is thus rolled back!
>>
>> 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.
>>>
>>
>
>
> >
>



-- 
Regards,
Karron

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

Reply via email to