在我的示例案例中，将 Unity 应用程序块或 DI 与实体框架结合使用有什么好处
在下面的伪代码中，我有 3 层：ASP.NET WebForms 应用程序的 UI、BL 和 DL。 有人可以给我一些关于为什么我需要使用依赖注入的指示吗 和统一在这里？我经常使用接口（主要用于邮件或文件解析器等第 3 方组件，因此我可以根据需要替换它们而不更改其他层），但我不明白为什么应该在 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.
}
In the pseudocode below I have 3 layers: UI, BL, and DL for ASP.NET WebForms app.
Can someone give me some pointers about why would I need to use Dependency Injection
and Unity here? I am using interfaces a lot (mostly for 3rd party components like Mail or File Parsers so I can replace them as needed without changing other layers), but I do not get why I should use interfaces on EF EntityObjects. I can not seem to find one example on the web which would show a practical advantage beyond theoretical unreal cases.
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.
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在你的场景中，你显然不需要它。当人们需要注入依赖项并将其替换为其他实现时，人们会使用依赖项注入 - 最常见的原因是自动化测试和模拟/伪造/存根依赖项。另一个原因是动态行为。
In your scenario you obviously don't need it. People use dependency injection when they need to inject dependencies and replace them with other implementation - most common reason is automated testing and mocking / faking / stubing dependencies. Another reasons are dynamic behaviors.
除了 Ladislav 提出的观点之外，还有其他一些观点： -
您可以使用 Unity 来装饰具有横切关注点的方法和类（在 Unity 中，这些称为行为）。您可以在任何地方使用行为，但我已将其与 EF 一起使用来执行以下操作：-
与设计相关更多，但使用依赖倒置原则，您可以更松散地耦合您的系统，例如您的 UI 不会引用业务层（并且可能与 EF 完全解耦，具体取决于您如何生成 ）
In addition to the points Ladislav has made, there are a few others: -
You can use Unity to decorate methods and classes with cross cutting concerns (in Unity these are called behaviours). You can use behaviours anywhere, but I have used this with EF to do things like: -
Slightly more design related, but using Dependency Inversion Principle you can more loosely couple your system so e.g. your UI does not reference the Business Layer (and potentially decoupled from EF entirely depending on how you're generating your entities).