Question

我试图了解何时以及如何以“正确的方式”使用UOW ..我知道很可能有一堆正确和错误的方法，在某些情况下，它可能会归结为如下“味道” ..

无论如何..我没有得到的是，几个月前我加入了一个项目，他们也在使用UOW来处理业务逻辑......在阅读了几篇关于它的帖子之后似乎没什么意义..因为我已经知道UOW的主要目的是处理从应用程序到数据源（数据库）的“事务”，对吗？

因此，例如在DDD中，您的存储库将成为UOW的一部分，因为您希望将DbContext（数据库连接）保持打开一段时间，以便您可以在多个存储库之间共享相同的DbContext，然后在一个事务中执行对同一个DbContex的所有更改...这有道理我猜...

但是将服务或工厂（在DDD中）放置作为UOW的一部分并不会有多大意义..因为它们不是（或至少不应该）与任何DbContext或数据库进行交互..

那么......用UOW“捆绑”Buisness Logic可以吗？例如：

var html = UnitOfWork.HtmlFactory.EncodeString("<p>some string</p>");
UnitOfWork.HtmlStringRepository.Add(html);
UnitOfWork.SaveChanges();

这甚至有意义吗？

这样做更有意义：

var html = HtmlFactory.EncodeString("<p>some string</p>");
UnitOfWork.HtmlStringRepository.Add(html);
UnitOfWork.SaveChanges();

...

哦！..在这种情况下，UnitOfWork是一个属性..所以是..它是一个对象引用，而不是一个带有一堆静态函数的类。

BR， INX

Answer 1

不，UnitOfWork应该将业务逻辑作为其中的一部分，它只关心事务边界。

此外，如果您正在实现任何编码逻辑，我将创建一个Value对象EncodedHtml，因为它代表了对业务有意义的东西。像这样

public class EncodedHtml
{
    public string Html {get; private set;}

    public EncodedHtml(string htmlToEncode){
        Html = EncodeHtml(htmlToEncode);
    }

    private string EncodeHtml(string htmlToEncode){
        // code 
        return htmlEncoded;
    }
}

现在无处不在我看到这个ValueObject我知道它已被编码和验证，所以我可以将它传递给我的实体，在这种情况下是HtmlString（不确定）。

Answer 2

工作单元会跟踪您在业务交易中可以影响数据库的所有操作。完成后，它会计算出因工作而改变数据库所需要做的一切。

引用来自Martin Fowler，但我添加了重点。我只看到了具有数据访问代码的工作单元模式，它通常不应该（可能曾经）包含任何业务逻辑。

所以我认为你的理解是正确的，示例代码确实看起来很奇怪。

您有没有问过您的团队他们想要实现的目标？

使用UnitOfWork for Business逻辑？

2 个答案: