将相关的实体框架模型分离到不同的程序集中

Question

想想这个典型的一对多关系：

public class Parent
{
    public int ID { get; set; }
    public virtual List<Child> Children { get; set; }
}

public class Child
{
    public int ID { get; set; }
    public int ParentID { get; set; }
    public virtual Parent ParentEntity { get; set; }
}

现在，如果这些实体与完全不同的业务层相关，而我们想在不同的程序集中声明它们呢？由于父实体需要知道其子实体类型，因此父实体需要引用子实体，反之亦然，从而创建循环引用。

我想到了三个问题：

1. 在不创建程序集之间的循环依赖关系的情况下，是否有任何非 hacky 方法来实现这一点？
2. 如果上述情况属实，是否意味着唯一受支持的方法是将来自特定上下文的所有实体存储在同一程序集中？ （如果您在单个数据库中有任何单独的不相关表集，为什么它们首先会属于同一个数据库？）
3. 您能否争辩说，如果它们与数据库相关，那么它们必然与业务相关，因此实体属于同一类？我想这个假设将取决于具体案例，但如果有人对此有强烈的感觉，我想听听关于这个主题的最佳实践的一些想法。

我知道网站上还有其他标题相似的问题，唯一真正提到相同概念的问题是this one，但它可能已经过时了，我发现问题及其唯一答案都非常模糊。

提前致谢

Answer 1

在不创建程序集之间的循环依赖关系的情况下，是否有任何非 hacky 方法来实现这一点？

执行此操作的正确方法是使用第三个程序集，该程序集定义了每种类型引用的接口：

组装3：

public interface IParent
{
    public int ID { get; set; }
    public List<IChild> Children { get; set; }
}

public interface IChild
{
    public int ID { get; set; }
    public int ParentID { get; set; }
    public IParent ParentEntity { get; set; }
}

然后在每个程序集中引用接口程序集。无论哪个程序集将父程序集和子程序集放在一起，然后引用所有三个程序集。

请注意，这可能并不容易。这可能意味着更多地手动链接类型，而不是让 EF 为您完成（因为 EF 将希望使用具体类型而不是接口）。因此，此时，您可以决定将这些类型放在单独的程序集中是否值得。

您能否争辩说，如果它们与数据库相关，那么它们必然与业务相关，因此实体属于同一类？

如果它们来自同一个数据库并且按照您的指示紧密耦合，那么是的，我会说将它们放在同一个程序集中是合理的。如果某些进程使用一个但不使用另一个，那么您可能可以选择加载另一种类型，但我需要了解更多有关细节的信息才能做出完整的建议（这超出了本论坛的范围）。