标签: unit-of-work

我正在寻找关于工作单元模式的一些建议.

工作单元上的提交是多次调用还是只调用一次,然后将对象保留为垃圾回收？

注入工作单元是一个好主意还是应该在请求对象执行某些工作时在方法调用中传递它？

我在网上看到了很多关于UnitOfWork和Repo Pattern的内容,但仍然没有清楚地了解为什么以及何时使用 - 这对我来说有点混乱.

考虑到我可以通过使用DI来使我的存储库可测试,如本文所述,使用IoC 什么是管理DataContext的最佳实践.我正在考虑将上下文作为对我的存储库构造函数的依赖进行传递,然后像这样处理它？:

public interface ICustomObjectContext : IDisposable {}
public IRepository<T> // Not sure if I need to reference IDisposable here
public IMyRepository : IRepository<MyRepository> {}

public class MyRepository : IMyRepository
{
    private readonly ICustomObjectContext _customObjectContext;

    public MyRepository(ICustomObjectContext customObjectContext)
    {
        _customObjectContext = customObjectContext;
    }

    public void Dispose()
    {
        if (_customObjectContext != null)
        {
            _customObjectContext.Dispose();
        }
    }

    ...

}

我目前对使用UnitOfWork和Repository Pattern的理解是在多个存储库中执行操作 - 这种行为似乎与@Ladislav Mrnka为Web应用程序推荐的内容相矛盾:

对于Web应用程序,每个请求使用单个上下 对于Web服务,每次调用使用单个上下文.在WinForms或WPF应用程序中,每个表单或每个演示者使用单个上下文.可能有一些特殊要求不允许使用这种方法,但在大多数情况下这已经足够了.

请在此处查看完整的答案

如果我理解正确的话,DataContext应该是短暂的,并且可以在每个请求或演示者的基础上使用(在其他帖子中也可以看到).在这种情况下,repo对上下文执行操作是合适的,因为范围仅限于使用它的组件 - 对吗？

我的回购在IoC中注册为瞬态,因此我应该为每个请求获得一个新的回购.如果这是正确的,那么我应该为每个请求获取一个新的上下文(上面的代码),然后处理它 - 说... 如果我关注,为什么我会将UnitOfWork模式与存储库模式一起使用上面的约定？

我是新手NHibernate,我正在尝试阻止Generic Repository Pattern和Unit of Work在ASP.NET MVC 3应用程序中使用.我用Google搜索了标题并找到了新的链接; 但是所有这些对我来说都更加复杂.我使用StructureMap作为我的IOC.你能建议我一些链接或博客文章吗？

我是测试驱动开发的新手,并尝试对mvc应用程序进行单元测试.我正在使用Moq和Ninject,并尝试遵循工作单元存储库模式.我收到所有测试的System.ArgumentException错误.这是错误消息和错误堆栈跟踪:

Test method LOMSv4.Tests.Controllers.AutobytelControllerTest.Index_Contains_All_Requests threw exception: 
System.ArgumentException: Can not instantiate proxy of class: LOMSv4_DAL.Autobytel.Concrete.RequestRepository.
Could not find a parameterless constructor.

参数名称:constructorArguments

Castle.DynamicProxy.ProxyGenerator.CreateClassProxyInstance(Type proxyType, List`1 proxyArguments, Type classToProxy, Object[] constructorArguments)
Castle.DynamicProxy.ProxyGenerator.CreateClassProxy(Type classToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, Object[] constructorArguments, IInterceptor[] interceptors)
Moq.Proxy.CastleProxyFactory.CreateProxy[T](ICallInterceptor interceptor, Type[] interfaces, Object[] arguments)
Moq.Mock`1.<InitializeInstance>b__0()
Moq.PexProtector.Invoke(Action action)
Moq.Mock`1.InitializeInstance()
Moq.Mock`1.OnGetObject()
Moq.Mock.GetObject()
Moq.Mock.get_Object()
Moq.MockDefaultValueProvider.ProvideDefault(MethodInfo member)
Moq.QueryableMockExtensions.FluentMock[T,TResult](Mock`1 mock, Expression`1 setup)
lambda_method(Closure )
Moq.Mock.GetInterceptor(Expression fluentExpression, Mock mock)
Moq.Mock.<>c__DisplayClass1c`2.<Setup>b__1b()
Moq.PexProtector.Invoke[T](Func`1 function)
Moq.Mock.Setup[T,TResult](Mock mock, Expression`1 expression, Func`1 condition)
Moq.Mock`1.Setup[TResult](Expression`1 expression)

这是我的测试类:

[TestClass]
public class AutobytelControllerTest …

我的应用程序越来越大,到目前为止,我有一个单独的MyDbContext应用程序所需的所有表.我希望(有关概述的缘故),以它们分开成多个DbContext,比如MainDbContext,EstateModuleDbContext,AnotherModuleDbContext和UserDbContext.

我不确定这是怎么做的可能因为我现在正在使用dependecy injection(ninject)将我的DbContext放在我的UnitOfWork类上,如:

kernel.Bind(typeof(IUnitOfWork)).To(typeof(UnitOfWork<MyDbContext>));

我应该通过依赖注入和显式设置放弃这种方法,DbContext我希望在我的服务上使用,例如:

private readonly EstateService _estateService;

public HomeController()
{
    IUnitOfWork uow = new UnitOfWork<MyDbContext>();
    _estateService = new EstateService(uow);
}

代替:

private readonly EstateService _estateService;

public HomeController(IUnitOfWork uow)
{
    _estateService = new EstateService(uow);
}

或者这有另一种更好的方法吗？另外作为一个附带问题,我不喜欢传递uow给我的服务 - 还有另一个(更好的)方法吗？

码

我有这个IDbContext和MyDbContext:

public interface IDbContext
{
    DbSet<T> Set<T>() where T : class;

    DbEntityEntry<T> Entry<T>(T entity) where T : class;

    int SaveChanges();

    void Dispose();
}

public …

我有一个 Doctrine 事件监听器来监听 onFlush 事件。我使用它在保存时更新实体上的电子标签。

我需要访问计划删除的实体，以便我可以访问它们的关联对象，但是：

我使用的是软删除过滤器，因此实体实际上并不在 中$uow->getScheduledEntityDeletions()，而是$uow->extraUpdates标记已删除的标志已更改。

该变量是私有的，我不知道有任何编程方式可以通知此更改。有任何想法吗？

private function updateIfRequired(OnFlushEventArgs $args)
{
    $em     = $args->getEntityManager();
    $uow    = $em->getUnitOfWork();



    // Entities either updated or just inserted
    $upsertedEntities = array_merge(

        $uow->getScheduledEntityUpdates(),
        $uow->getScheduledEntityInsertions()
    );

    foreach ($upsertedEntities as $entity) {

        if ($entity instanceof ETaggableInterface || $entity instanceof ETagRelatedInterface) {
            $this->updateETag($entity);
        }
    }

    // When soft-deleted, this and getScheduledEntityUpdates are both empty!
    $deletedEntities = $uow->getScheduledEntityDeletions();

    foreach ($deletedEntities as $entity) {

        $this->deletedEntities[spl_object_hash($entity)] = $entity;
        $this->updateETag($entity);
    }

}

我想知道关于它的正确概念.如果我有一个带存储库模式的MVC应用程序,BL应该在哪里？

• 它应该在模型中吗？在调用unitofwork之前,模型应该具有所有业务逻辑以将数据插入数据库中吗？

• 它应该在控制器中吗？在打电话给模特之前？

• 我是否应该有一个服务层来执行业务逻辑并决定是否应该调用Model来调用UnitOfWork来保存数据？

一个好的解释也会有很大帮助.

我有一个表,其中包含Id作为主键和LastMeterReadingId(引用同一个表的外键)之类的列 - 类似于Parent Meter Reading.

我想得到所有尚未使用的行,如Parent.我想避免当抄表是超过一米读数的父母时的情况.

我知道如何加入同一个表,但我不知道如何只选择那些不是父表的记录.这就是没有条件语句的查询的样子.

return (from m in uow.MeterReadingReadWriteRepository.Query()
                join parent in uow.MeterReadingReadWriteRepository.Query() on m.Id equals parent.LastMeterReadingId

                select new MeterReadingDto()
                {
                    (...)
                }).ToList();

你知道如何以有效的方式实现它吗？

问候.

我将在我的数据访问层中使用存储库和UnitOfwork来执行此操作,查看一个联系人aggregateroot

 public interface IAggregateRoot
    {
    }

这是我的Generic存储库接口:

 public interface IRepository<T>
        {
            IEnumerable<T> GetAll();
            T FindBy(params Object[] keyValues);
            void Add(T entity);
            void Update(T entity);
            void Delete(T entity);

        }

和我在模型中的POCO Contact类

 public class Contact :IAggregateRoot
        {
            public Guid Id { get; set; }
            public string Name { get; set; }
            public string Email { get; set; }
            public string Title { get; set; }
            public string Body { get; set; }
            public DateTime CreationTime { get; set; }
        }

这是我继承自IRepository的IContactRepository,也可能是自己的方法

 public interface …

首先，让我们看看微软对Asp.Net Core的默认依赖注入服务的看法：

该框架负责创建依赖项实例，并在不再需要它时将其处置。

https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1#disposal-of-services

即框架将调用类Dispose方法（假设该类实现IDisposable）

其次，DbContext类确实确实实现了IDisposable。

第三，在我们的Startup.cs类中，我们通过AddDbContext方法添加DbContext，默认情况下，该方法将作为Scoped实例添加（即，我们的DbContext被创建并在每个单个请求上进行垃圾回收）。

每个请求一次创建范围的生命周期服务。

https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1#service-lifetimes

例如

public void ConfigureServices(IServiceCollection services)
{
    services
        .AddDbContext<TheStoreDbContext>(ConfigureDbContext)      
        .AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2) 
}

结论，我们不需要在Asp.net Core应用程序中的任何位置显式调用context.Dispose（）。

那么，为什么在线上和教程中有如此多的示例向您显示必须在Repository或UnitOfWork类中实现IDisposable？

例如

public class UnitOfWork : IUnitOfWork
    {
        private readonly DbContext _context;

        public IProductRepository ProductRepository { get; }

        public UnitOfWork(DbContext context)
        {
            _context = context;
            ProductRepository = new ProductRepository(context);
        }

        public void Dispose()
        {
            _context.Dispose();
        }
    }

你怎么看？这是一个有效的问题吗？不在任何地方显式调用Dispose（）方法是否有意义？