与我的示例案例一样，通常将Unity Application Block或DI与Entity Framework一起使用有什么好处

如何解决与我的示例案例一样，通常将Unity Application Block或DI与Entity Framework一起使用有什么好处

| 在下面的伪代码中，我分为3层：用于ASP.NET WebForms应用程序的UI，BL和DL。 有人可以给我一些关于为什么我需要使用依赖注入的建议吗 和团结在这里？我使用了很多接口（主要用于邮件或文件解析器之类的第三方组件，因此我可以根据需要替换它们而无需更改其他层），但是我不明白为什么我应该在EF EntityObjects上使用接口。我似乎无法在网络上找到一个示例，该示例将显示出超出理论上不真实案例的实际优势。

namespace Sample.ASP.NET.UI
{

  using Sample.ASP.NET.BusinessLayer;
  using Sample.ASP.NET.DataModel;

  protected class AspxCodeFile
  {
      protected Page_Load()
      {
          GridView.DataSource=BusinesLayer.Products.GetProductsAsList();
      }
   }
}

namespace Sample.ASP.NET.BusinessLayer
{
  using Sample.ASP.NET.DataModel;

  protected class Products
  {
    public static List<Product> GetProductsAsList()
    {
      EdmxEntities DB=new EdmxEntities();
      return DB.Products.ToList<Product>();
    }
  }
}

namespace Sample.ASP.NET.DataLayer
{
    // wrapper namespace for Entity Framework designer
    // generated code off SQL Server 2008 database
    // where one of the tables is called Products
    // and designer created Product EntityObject
    // this Product entity is referenced in both
    // UI and BL.
}

    

解决方法

        在您的方案中，您显然不需要它。人们在需要注入依赖关系并将其替换为其他实现时会使用依赖关系注入-最常见的原因是自动测试和模拟/伪造/存根依赖关系。另一个原因是动态行为。     ,        除了拉迪斯拉夫提出的观点外，还有其他几点：- 您可以使用Unity来装饰具有交叉关注点的方法和类（在Unity中这些行为称为行为）。您可以在任何地方使用行为，但是我已经将它与EF结合使用来执行以下操作：- 自动创建/保存/清除对象上下文 自动缓存例如参考数据 记录方法调用时间以查找DAL上的性能瓶颈 与设计的相关性稍高一些，但是使用“依赖倒置原理”，您可以更轻松地耦合系统，例如您的用户界面未引用业务层（并可能完全取决于实体生成方式而与EF分离）。