工作范围单元

Question

我有一个使用网络表单作为前端的解决方案mvc 用于管理控制台。

两个 UI 都通过 Ninject 消耗服务层，我在解决一个微妙但相当重要的问题时遇到了困难。

假设我有一个 CourseService，它根据字符串搜索词返回课程列表 - 该服务返回搜索结果，但我还需要记录所做的搜索，以及有多少课程与该词匹配，以用于管理信息。

我一开始的想法是，工作单元将由 UI 在请求结束时在页面方法（例如按钮单击事件）中提交。这同样适用于控制器。

这里的问题是我依赖 UI 开发人员在工作单元上调用 Commit() 以便记录搜索。 UI 开发人员可以愉快地继续而不调用 commit，并且结果将被返回 - 但搜索不会被记录。这导致我决定让服务层控制工作单元的范围。 Ninject 会自动将工作单元传递给服务层和存储库实现，这实际上与我告诉 ninject 根据请求范围创建它的实例相同。

这是我的层的编写方式的示例...

public class CourseService
{
    private readonly ICourseRepository _repo;

    public CourseService(ICourseRepository repo)
    {
        _repo = repo;
    }

    public IEnumerable<Course> FindCoursesBy(string searchTerm)
    {
        var courses = _repo.FindBy(searchTerm);
        var log = string.format("search for '{1}' returned {0} courses",courses.Count(),searchTerm);
        _repo.LogCourseSearch(log);
        //IMO the service layer should be calling Commit() on IUnitOfWork here...
        return courses;
    }
}

public class EFCourseRepository : ICourseRepository
{
    private readonly ObjectContext _context;

    public EFCourseRepository(IUnitOfWork unitOfWork)
    {
        _context = (ObjectContext)unitOfWork;
    }

    public IEnumerable<Course> FindBy(string text)
    {
        var qry = from c in _context.CreateObjectSet<tblCourse>()
            where c.CourseName.Contains(text)
            select new Course()
            {
                Id = c.CourseId,
                Name = c.CourseName
            };
        return qry.AsEnumerable();
    }

    public Course Register(string courseName)
    {
        var c = new tblCourse()
        {
            CourseName = courseName;
        };
        _context.AddObject(c);
        //the repository needs to call SaveChanges to get the primary key of the newly created entry in tblCourse...
        var createdCourse = new Course()
        {
            Id = c.CourseId,
            Name = c.CourseName;
        };
        return createdCourse;
    }
}

public class EFUnitOfWork : ObjectContext, IUnitOfWork
{
    public EFUnitOfWork(string connectionString) : base(connectionString)
    {}

    public void Commit()
    {
        SaveChanges();
    }

    public object Context
    {
        get { return this; }
    }
}

在上面的评论中，您可以看到我认为我“应该”提交更改的位置，但我觉得通过允许服务层和存储库实现来控制事务范围。

除此之外，当我的存储库需要保存一个新对象，并在新给定的主键完好无损的情况下返回它时，如果我在返回对象后从 UI 调用 Commit，则不会发生这种情况。所以存储库有时确实需要管理工作单元。

您能看出我的方法有什么直接问题吗？

Answer 1

这就是您工作单元的“边界”。你的逻辑运算的边界是什么？是 UI - 代码隐藏/控制器还是服务层？我所说的边界是指谁定义了什么是工作单元？ UI 开发人员有责任编排对单个工作单元的多个服务调用，还是服务开发人员有责任公开每个包装单个工作单元的服务操作？这些问题应该可以立即为您提供答案，其中应该在工作单元上调用 Commit。

如果逻辑操作的边界是由 UI 开发人员定义的，那么您就不能这样做 - 永远不会。 UI 开发人员可以在调用您的方法之前进行一些未提交的更改，但一旦您记录搜索，您将默默地提交这些更改！在这种情况下，您的 Log 操作必须使用自己的上下文/工作单元（而且它应该在当前事务之外运行），这将需要单独的 ninject 配置为每个调用创建新的 UoW 实例。如果逻辑操作的边界在服务中，则不应向 UI 开发人员公开工作单元 - 他不应该能够与活动的 UoW 实例进行交互。

我不喜欢您的实现是 Register 在工作单元上调用 Commit 。再说一遍，边界在哪里？存储库操作是独立的工作单元吗？在这种情况下为什么还要有服务层呢？如果您想在单个工作单元中注册多个诅咒，或者希望课程注册成为更大工作单元的一部分，会发生什么情况？服务层负责调用Commit。这整个可能来自于这样的想法：您的存储库将把实体投影到自定义类型/DTO 中 - 它看起来对存储库承担了太多的责任并且太复杂了。特别是如果您可以使用 POCO (EFv4.x)。

最后要提到的是，一旦您将服务操作作为工作单元的边界，您就会发现每个请求实例化是不够的。您可以拥有将在内部执行多个工作单元的网络请求。

最后。您关心 UI 开发人员的职责 - 同时 UI 开发人员可以关心您的实现 - 如果 UI 开发人员决定并行运行多个服务操作会发生什么（EF 上下文不是线程安全的，但您只有一个）对于整个请求处理）？因此，这一切都与您和 UI 开发人员之间的沟通有关（或与非常好的文档有关）。