工作单元和存储库模式
我有一个使用 NHibernate 的存储库模式设置。基类如下所示:
public interface IUnitOfWork : IDisposable
{
void Commit();
void Rollback();
}
// generic NHibernate implementation of IUnitOfWork here
public class NHibernateRepositoryBase<T> : IRepository<T>
{
private NHibernateUnitOfWork _unitOfWork;
public NHibernateRepositoryBase(NHibernateUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
}
public T Get(object id)
{
return _unitOfWork.Session.Get<T>(id);
}
// ...
}
如您所见,我允许通过构造函数(使用 StructureMap)填充工作单元。我正在我的 ASP.NET Web 服务上填充存储库对象,如下所示:
[WebService(Namespace = "...")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class ModuleService : System.Web.Services.WebService
{
public IUserAccountRepository UserAccountRepo { get; set; }
public ModuleService()
{
// tell IoC to inject properties
ObjectFactory.BuildUp(this);
}
// ...
}
正如您可能推断出的那样,我的问题是,通过设计,我现在失去了对工作单元生命周期的控制。以前,我将工作单元设置为上下文敏感对象,存储库将通过以下方式获取对它的引用:
public class NHibernateRepositoryBase<T> : IRepository<T>
{
public T Get(object id)
{
return NHibernateUnitOfWork.GetCurrent().Session.Get<T>(id);
}
// ...
}
以前的设计允许我通过创建工作单元来控制代码中工作单元的生命周期using 语句中的 UnitOfWorkFactory。我试图将更多的工作交给 IoC 容器,但我认为我实际上倒退了一步。您对这两种实施方式有何看法?
I have a repository pattern setup using NHibernate. The base class looks like this:
public interface IUnitOfWork : IDisposable
{
void Commit();
void Rollback();
}
// generic NHibernate implementation of IUnitOfWork here
public class NHibernateRepositoryBase<T> : IRepository<T>
{
private NHibernateUnitOfWork _unitOfWork;
public NHibernateRepositoryBase(NHibernateUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
}
public T Get(object id)
{
return _unitOfWork.Session.Get<T>(id);
}
// ...
}
As you can see, I'm allowing the unit of work to be populated via the constructor (using StructureMap). I'm populating the repository objects on my ASP.NET web services like so:
[WebService(Namespace = "...")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class ModuleService : System.Web.Services.WebService
{
public IUserAccountRepository UserAccountRepo { get; set; }
public ModuleService()
{
// tell IoC to inject properties
ObjectFactory.BuildUp(this);
}
// ...
}
As you may be able to deduce, my problem is that by way of design, I've now lost control of the lifecycle of the unit of work. Previously, I made the unit of work a context sensitive object and the repository would obtain a reference to it via something like:
public class NHibernateRepositoryBase<T> : IRepository<T>
{
public T Get(object id)
{
return NHibernateUnitOfWork.GetCurrent().Session.Get<T>(id);
}
// ...
}
This previous design allowed me to control the life cycle of the unit of work in my code by creating the unit of work from a UnitOfWorkFactory within a using statement. I was trying to put more of the work in the hands of the IoC container, but I think I actually took a step backwards. What are your thoughts on either implementation?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
让 IoC 容器处理尽可能多的事情通常是一件好事。在网络上,工作单元模式通常在请求开始时初始化并在结束时提交(如果有任何异常则回滚)。这样,您的存储库将在构造函数中采用 ISession 而不是工作单元。这样,您的存储库将不必处理提交或任何其他事情,并且将自动为您处理。
It is usually a good thing to let your IoC container handle as much as possible. On the web a unit of work pattern usually get initialized at the start of the request and committed at the end (rolled back if there is any exceptions). This way your repository will take a ISession in the constructor instead of the unitofwork. This way, your repository will not have to deal with committing or anything and that will be handled automatically for you.