Question

在下面的伪代码中，我有3层：ASP.NET WebForms应用程序的UI，BL和DL。有人可以给我一些指示，说明为什么我需要使用依赖注入和Unity在这里？我经常使用接口（主要用于第三方组件，如Mail或File Parsers，所以我可以根据需要替换它们而不更改其他层），但我不明白为什么我应该在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.
}

Answer 1

在您的方案中，您显然不需要它。人们在需要注入依赖项时使用依赖项注入，并将其替换为其他实现 - 最常见的原因是自动化测试和模拟/伪造/存根依赖项。另一个原因是动态行为。

Answer 2

除了Ladislav所提出的观点之外，还有其他一些观点： -

您可以使用Unity来装饰具有横切关注点的方法和类（在Unity中，这些被称为行为）。你可以在任何地方使用行为，但我在EF中使用它来执行以下操作： -
- 自动创建/保存/清除对象上下文
- 自动缓存例如参考数据
- 记录方法调用时间以查找DAL上的性能瓶颈
稍微多一些设计相关，但使用依赖倒置原则，您可以更松散地耦合您的系统，例如您的用户界面不会引用业务层（并且可能完全与EF分离，具体取决于您生成实体的方式）。

在我的示例中，使用Unity应用程序块或DI通常与Entity Framework有什么好处

2 个答案: