实体框架循环dll参考

Question

我在当前（悲伤）状态下的解决方案：

我希望我的业务层数据提供者不可知（不是一件好事吗？），只需一个接口，这样我就可以将NHibernate或Linq的EF切换到Xml或我或老板想使用的任何类型的持久性提供程序（或新优胜者，将在此项目完成后2秒内不可避免地被发明出来）。

IPersistenceProvider是该接口，我可以将其注入Unity（而不是游戏平台，DI容器）。 对我来说， IPersistenceProvider属于数据层，我们可以继续添加文件夹（例如EntityFramework ），因为需要将新的持久性范例添加到我的简历（或项目）中。

因此，我的业务dll取决于我的数据dll。 这是业务dll中的一些代码，具体取决于数据dll：

using System;
using Atlas.Data.Kernel;

namespace Atlas.Business.Kernel
{
  public abstract class BusinessObject
  {
    public BusinessObject(IPersistenceProvider p)
    {

    }


    public Guid Id;

  }
}

我也觉得我的DatabaseContext属于数据层。 但是EF使您可以为其DbSet引用具体类型，这意味着Atlas Data Kernel dll将需要依赖于Atlas Business Kernel dll，后者将成为循环dll引用。 En plus（此外，它是法语的），对我来说，数据层有点指向业务层具体类型。 DatabaseContext希望在业务dll中上线，但这将我的业务层与特定的持久性策略工件耦合在一起。

如何解决呢？ 我可以将其折叠到一个dll中（确实，我在以前的项目中做了这个事情），但是那有点糟，我将无法进入.Net Architects俱乐部。 他们会嘲笑我的“ 1 N太少”架构，并在会议中对我大笑。 WWDED？ （ Dino Esposito会做什么？ ）

Answer 1

从实现中拆分声明。

EntityFramework子目录应该是一个单独的程序集（例如AtlasDataKernelEF），其中包含EF内容和IPersistenceProvider的实现，从而解决了循环引用。

另外，如果您真的需要使用其他ORM，则可以摆脱所有EF库的生产可执行文件。

您没有勾画如何实例化EF数据访问，但是您确实需要将其包装在某种工厂类中。

Answer 2

您的项目AtlasBusinessKernel不应引用AtalsDataKernal类中的任何资源。 AtalsBusinessKernel需要使用的AtalsDataKernal中的任何资源都应表示为AtalasBusinessKernal项目中的接口，可以是IDataConext接口或存储库接口。

仅当您有第三个项目实际使用AtalsBusinessKernal项目（可能是表示UI的Web应用程序或控制台应用程序）时，这才起作用。 该项目将负责实例化DatabaseContext，最好使用DI。

// In your AtlasDataKernal
public class DatabaseContext : IDataContext
{
      // implementation
}

// In your AtlasBusinessKernal
public class MyBusinessLogic
{
     private IDataContext dataContext;
     public MyBusinessLogic(IDataContext context)
     {
        this.dataContext = context;
     }
}
// In your web application or whatever project type it might be
public class MyWebApp
{
      public DoSomeThing()
      {
          IDataContext context = new DatabaseContext();
          MyBusinessLogic logic = new MyBusinessLogic(context);
      }
}