Question

想想这个典型的1到多个关系：

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

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

我想到了三个问题：

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

我知道网站上还有其他类似标题的问题，实际上只提到同一个概念的问题是this one，但它可能已经过时了，我发现这个问题及其唯一答案模糊。

提前致谢

Answer 1

在没有在程序集之间创建循环依赖关系的情况下，是否有任何非hacky方法可以实现此目的？

执行此操作的正确方法是使用第三个程序集定义每个类型引用的 interfaces ：

assembly3：

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会想要使用具体类型而不是接口）。那么在那时，您可以决定是否将这些类型放在单独的程序集中是值得的。

你是否认为如果它们与数据库相关，那么它们必须与业务相关，因此实体属于一起？

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

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

1 个答案: