开发者

ASP.NET MVC - Unit Of Work vs Session

开发者 https://www.devze.com 2023-03-25 20:08 出处:网络
Here at company we have several projects using ASP.Net MVC, jQuery, LinqToSql and StructureMap . Suppose I have this situation: A Company edit page. This page has 2 tabs: Details and Employees. Deta

Here at company we have several projects using ASP.Net MVC, jQuery, LinqToSql and StructureMap .

Suppose I have this situation: A Company edit page. This page has 2 tabs: Details and Employees. Details is just company details, such as name, phone etc. In Employees tab, I have a jquery grid will all Company Employees. These Employees are coming from a Session, because a user can edit an employee, delete, etc and all of these modifications will be set on the same Session. And, user can edit an employee so many times he wants, add a new employee, delete this same new employee and so on.

At the bottom of this page, I have Save and Cancel buttons. When Save is clicked, I get the employees from the Session and save to database. This kinda work.

One day, some collegue said that we should give up on using Session and start using Unit of Work. So, I began to read some articles, blogs etc about it.

What I didn't understand so far is how I can drop using Session and s开发者_运维问答tart using UoW to persist all my data... to persist correctly all of the things user did in the page.

I didn't find anything in some pratical ways so far.

Thanks in advance!


Actually, UoW is just a pattern for persisting data not a replacement for the Session. The Session will still be used, it just that the UoW will be responsible with interacting with the NHibernate Session. A typical UoW implementation may look something like this:

public ActionResult Edit(Employee model)
{
   using(IUnitOfWork uow = UnitOfWork.Start())
   {
       employeeRepository.Save(model);

       uow.Commit();
   }

   return Json("Success); 
}

Here you are explicitly marking the boundary of your transaction as opposed to passing a Session around. A great resource for implementing UoW for NHibernate can be found here.


I think what you're getting at is you want a façade type pattern. You create an interface or base class to deal with getting & saving user data. you then create a concrete class that uses the session.

When you want to change to unit of Work, or any other mechanism, you just create a new concrete implementation & use that. you code is now oblivious to where your data is held.

Simon

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号