标签: unit-of-work

我当前的应用程序结构是：

• 模型组装
• 数据组装
  • 定义由 ORM 实现的存储库接口
• ORM组装
  • 从数据组装实现存储库接口
  • 使用unity（IoC容器）来Data.IRepository<>注册ORM.GenericRepository<>
• 业务组装
  • 引用数据和模型程序集
  • 使用 unity 来解决类型IRepository<>
• 用户界面组装
  • 参考业务程序集

这种结构本质上将业务层与实现IRepository<T>.

这种解耦结构的好处之一是我应该能够相对轻松地替换 ORM - 例如，从实体框架迁移到 NHibernate 或仅升级现有的 ORM。我目前首先使用 EF 4.1 代码，并正在为 NHibernate 构建另一个程序集。

我正在考虑实施工作单元模式。

我读到，这种模式应该在业务层中使用（在我的数据程序集中定义接口，并在 ORM 程序集中实现，就像我对存储库模式所做的那样）。目前，所有实例化存储库都有自己的 DbContext / 会话，并且其生命周期设置为存储库的生命周期 - 这可能很糟糕 - 我的问题是我不确定是否可以实现可以使用的工作单元模式不同的 ORM（呃，更确切地说，它可能是，我只是不跟上速度）。

这是我唯一想到的事情：

在我的数据程序集中创建具有以下功能的 IUnitOfWork：object GetCurrentSession();，然后在 ORM 程序集中的存储库的构造函数中添加一个参数，并将其转换为适当的会话/DbContext（如果是 NHibernate，则为 ISession，如果是 Entity Framework，则为 DbContext）

如果有人对这种情况有所了解，我将不胜感激。

我只是想开始学习 NHibernate，在使用极其简单的 POCO 进行测试时我已经遇到了问题。我收到 No Persister 异常，这是我的代码：

Account桌子：

create table Account
(
    AccountID int primary key identity(1,1),
    AccountName varchar(10),
    CreateDate datetime
)
go

Account班级：

public class Account
{
    public virtual int AccountID { get; set; }
    public virtual string AccountName { get; set; }
    public virtual DateTime CreateDate { get; set; }

    public Account()
    {
        AccountID = 0;
        AccountName = "";
        CreateDate = new DateTime();
    }
}

映射文件Account.hbm.xml（是的，它嵌入到程序集中）：

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   namespace="NHibernateTesting" assembly="NHibernateTesting"> …

我想问如何构建一个类似于 TFS 用于查询的查询生成器引擎，该引擎将允许用户组合多个条件，并在后端使用 EF 来根据条件查询数据。

类似于：用户构建查询 -> 将 json 发送到后端 -> 后端以 EF 代码优先 + 存储库模式处理查询。

有一个 jquery 查询构建器插件，但如何将该 json 转换为 EF 存储库模式？

jQuery 查询生成器：jquery 查询生成器

首先，如果这个问题已经得到回答，我很抱歉。但我无法找到解决方案。

假设我想创建一个订单以及一些行，同时创建另一个实体。

服务层：

public class OrderService
{
    private DbContext context;

    public OrderService()
    {
        context = new DbContext();
    }

    public void AddOrder(Order order, List<Orderline> lines, AnotherEntity anotherEntity)
    {
        context.Orders.Add(order);
        context.Orderlines.AddRange(lines);

        var anotherService = new AnotherService();
        anotherService.AddAnother(anotherEntity)

        context.SaveChanges();
    }
}

public class AnotherService
{
    private DbContext context;

    public AnotherService()
    {
        context = new DbContext();
    }

    public void AddAnother(AnotherEntity entity)
    {
        // Maybe some business rules here

        context.SomeOtherEntities.Add(entity);

        context.SaveChanges();
    }
}

控制器：

var orderService = new OrderService();
orderService.Add(order, lines, anotherEntity);

第一个问题是我在两个服务中有不同的上下文，因此有两个不同的事务。我能想到的解决方案：

1. 将 dbcontext …

我知道这个问题之前已经被问过好几次了，但我找不到我想要的答案。因此，我实现了存储库（通用）和 UOW 模式，因此我可以使用 EF 访问我的数据库。这是 UnitOfWork 类的一部分：

    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                entities.Dispose();
            }
        }
        this.disposed = true;
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

问题是：谁在调用 void Dispose 方法？我还没有看到使用该方法的示例。

这是工作单元类的上半部分：

    private BDEntities entities = null;

    public UnitOfWork()
    {
        if (entities == null)
        {
            entities = new BDEntities();
        }
    }

这是正确的吗？我应该使用“使用”吗？如果是，那么为什么我需要 Dispose 方法？

您能给我一个正确且简单用法的例子吗？

谢谢你，罗特姆

在浏览了多篇堆栈溢出帖子和博客文章后，我做出了这样的决定：我们需要UnitOfWork 设计模式来维护事务完整性，同时将域对象写入各自的存储库。

然而，我们在阅读/搜索存储库时不需要这种完整性。鉴于此，将存储库和工作单元的用途分开，前者仅用于读取域对象，后者仅用于创建/写入/刷新/删除域对象，这是一个好的设计吗？

在 Martin Fowler 的书中，我读到了有关UnitOfWork和IdentityMap 模式的内容。

作者提到将 IdentityMap 放入 UnitOfWork 中是一个好主意。但怎么办呢？

据我了解IdentityMap，受会话限制，但作者没有提到这一点UnitOfWork

1. 实例是否UnitOfWork受会话限制？

2. 假设我们有客户和订单实体。

   public clas Client{
   
        List<Order> orders;
       ...
   }
   

   Run Code Online (Sandbox Code Playgroud)

我们收到更新客户信息（电话号码）并添加新订单的请求：

这里需要多少个unitOfWork实例？每个会话？我们应该为客户和订单提供单独的实例吗？

我们这里需要多少个 IdentityMap 实例？对于每个实例？我们应该为客户和订单提供单独的实例吗？

每个unitOfWork 实例需要多少个IdentityMap 实例？

如果我们有 2 个并发请求怎么办？

我在我的项目中使用 UnitOfWork 和 Repository 模式。我正在尝试编码干净。

这是我的IUnitOfWork.cs （应用层）

public interface IUnitOfWork : IDisposable
{
    int Save();
    IGenericRepository<TEntity> Repository<TEntity>() where TEntity : class;
}

UnitOfWork.cs的实现：（持久层）

public class UnitOfWork : IUnitOfWork
{      
    private readonly DBContext _context;
    private Hashtable _repositories;
    public UnitOfWork(DBContext context)
    {
        _context = context;
    }

    public IGenericRepository<T> Repository<T>() where T : class
    {
        if (_repositories == null)
            _repositories = new Hashtable();

        var type = typeof(T).Name;

        if (!_repositories.ContainsKey(type))
        {
            var repositoryType = typeof(GenericRepository<>);

            var repositoryInstance =
                Activator.CreateInstance(repositoryType
                    .MakeGenericType(typeof(T)), _context);

            _repositories.Add(type, …

我正在尝试在现有项目中使用Sequelize和 Typescript 来实现存储库和工作单元模式，遵循域驱动设计。然而，由于互联网上缺乏相关示例，我遇到了一些困难。

interface IPostRepo {
    save(post: Post): Promise<void>;
}

interface ICommentRepo {
    save(comment: Comment): Promise<void>;
    saveBulk(comments: Comment[]): Promise<void>;
}

class SequelizePostRepo implements IPostRepo {
    private models: any;
    private commentRepo: ICommentRepo;

    constructor(models: any, commentRepo: ICommentRepo) {
        this.models = models;
        this.commentRepo = commentRepo;
    }

    public async save(post: Post): Promise<void> {
        const PostModel = this.models.Post;
        const rawSequelizePost = await PostMap.toPersistence(post);

        await PostModel.create(rawSequelizePost);
        await this.commentRepo.saveBulk(comments);
    }
}

class SequelizeCommentRepo implements ICommentRepo {
    private models: any;

    constructor(models: …