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

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

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; }
}

现在，如果这些实体与完全不同的业务层相关，并且我们希望在不同的程序集中声明它们，该怎么办？由于父实体需要了解其子实体类型，因此父实体的程序集需要引用子实体的程序集，反之亦然，从而创建循环引用

我想到三个问题：

是否有任何非黑客方法可以在不创建程序集之间的循环依赖关系的情况下实现这一点？ 如果上述情况属实，是否意味着唯一受支持的方法是将特定上下文中的所有实体存储在同一程序集中？如果在单个数据库中有任何独立的不相关表集，为什么它们首先会属于同一个数据库？ 如果它们是数据库相关的，那么它们就必须是业务相关的，因此这些实体属于一个整体，你能说吗？我想这一假设将取决于具体案例，但如果有人有强烈的感觉，我想听听关于这方面最佳实践的一些想法。 我知道网站上还有其他类似标题的问题，唯一一个真正提到这个相同概念的是，但它可能已经过时了，我发现这个问题和它的唯一答案都很模糊

提前谢谢

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

正确的方法是使用第三个程序集来定义每个类型引用的接口：

大会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希望使用具体的类型而不是接口。因此，此时，您可以决定是否值得费心将这些类型放在单独的程序集中

如果它们是数据库相关的，那么它们就必须是业务相关的，因此这些实体属于一个整体，你能说吗

---

如果它们来自同一个数据库，并且像您所指出的那样紧密耦合，那么是的，我认为将它们放在同一个程序集中是合理的。如果某些进程使用其中一种，而不是另一种，那么您可能可以选择加载另一种类型，但我需要了解更多细节，以提出一个完整的建议，这将超出本论坛的范围。

谢谢您的想法！我一开始没有想到接口，因为我通常将它们与行为联系起来，而不是与数据联系起来，但在这种情况下，这个想法正好适合克服您指出的EF的困难。。。。我没有这个场景的任何具体例子，因为我只是在阅读有关EF的文章时随机思考如何使用EF。