工作单元和存储库模式

发布于 2024-08-17 19:55:25 字数 1445 浏览 4 评论 0原文

我有一个使用 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

挽你眉间 2024-08-24 19:55:25

让 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文