Question

在开发新应用程序时，我们尝试遵循DDD的原则。 EF2.1用于保留实体。

在许多情况下，具有一个聚合的实体可能会引用另一个聚合中的某些内容。例如，我的订单可以引用客户。在Order实体上，我们通过保持外键值来实现这一点。过度简化的模型。

public class Order
{
    DateTime OrderDate {get; set;}
    int CustomerId {get; set;}
}

public class Customer
{
    int Id {get
    string Name {get; set;}
}

我们没有在Order对象上包含任何导航属性到Customer对象，因为它模糊了聚集的边界

对于可能需要列出订单并包括下订单的客户名称的需求，团队的首选项是使用EF和Linq查询数据，并使用Automapper映射到Dto以返回给客户应用程式。没有导航属性，很难包括相关的客户来检索名称。

虽然EF非常适合持久化聚集体，但如果您没有导航属性，则使用EF来查询读取模型的数据可能会很复杂。在我看来，使用像Dapper之类的普通旧SQL对于这种类型的读取来说会比较容易（并且可能会有更高的性能）。团队正在斗争，不想使用SQL。这导致在某些情况下添加了导航属性，或者对实体添加了非常复杂的linq查询。

对于创建读取模型应该采取的方法，有人有什么强烈的看法？

Answer 1

我的订单可以参考客户。在Order实体上，我们通过保持外键值来实现这一点。

列出订单并包括下订单的客户的名字

然后，您需要使用Customer来获得Order.CustomerId

using(var ctx = new Context())
{
    var orderWithCustomerName = ctx
        .Order
        .Select(o => new OrderWithCustomerName
        {
            Order = o,
            Customer = ctx.Customer.First(c => c.Id == o.CustomerId)
        })
        .ToList();
}

遵循DDD

1 个答案: