如何将 ninject 自身注入到具有扩展函数的静态类中
我得到了一些带有扩展方法的静态类，这些扩展方法使用存储库模式向实体添加“业务逻辑”。
现在有时我需要在这些扩展函数中创建一个新的IRepository。
我目前正在通过我扩展的对象访问我的 Ninject 内核来解决这个问题，但这真的很难看：
public static IEnumerable<ISomething> GetSomethings(this IEntity entity)
{
using (var dataContext = entity.kernel.Get<IDataContext>())
return dataContext.Repository<ISomething>().ToList();
}
我还可以创建一个静态构造函数，以某种方式从工厂访问 Ninject 内核，Ninject 中是否已经有相应的基础设施2？
有人知道更好的解决方案吗？有人对这种实现业务逻辑的方式有什么评论吗？
I got some static classes with extension methods which add 'business logic' to entities using the repository pattern.
Now sometimes i need to create a new IRepository in these extension functions.
I'm currently working around it by accessing my Ninject kernel through the object I'm extending, but it's really ugly:
public static IEnumerable<ISomething> GetSomethings(this IEntity entity)
{
using (var dataContext = entity.kernel.Get<IDataContext>())
return dataContext.Repository<ISomething>().ToList();
}
I could also make a static constructor, accessing the Ninject kernel somehow from a factory, is there already infrastructure for that in Ninject 2?
Does anybody know a better solution? Does anybody have some comments on this way to implement business logic.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
关于扩展方法以及它们如何获取内容的问题。您有两种方法：
服务位置 - 拥有全局内核并下拉到服务位置（这与依赖注入不同）。但这里的问题是，您的实体（或其扩展）不应该假设其上下文，而是要求它
因为您是一个扩展方法，所以您正在扩展的东西会传递给您您需要的内容
正如你或多或少猜到的那样，Ninject 试图阻止你这样做（拥有一个成为垃圾场的全局内核）。一般来说，无论您使用什么，扩展（例如，MVC 或 WCF）都会在适当的情况下提供一些东西。例如，WCF 扩展具有 http://github.com/ninject/ninject.extensions.wcf/blob/master/source/Ninject.Extensions.Wcf/NinjectServiceHost.cs
这里更大的问题是像这样的依赖项可能不应该向下传播到实体级别 - 它应该停留在服务级别并从那里传播（使用 DDD 词汇）。
您可能会找到我的这个答案< /a> 很有趣，因为它稍微涵盖了这个领域（更多来自架构概念角度的 Ninject 技术）
On the issue of extension methods and how they get stuff. You have two approaches:
Service Location - have a global Kernel and drop down to Service Location (which is different from Dependency Injection). The problem here though is that your Entity (or its extensions) should not be assuming its context and instead demanding it
As you are an extension method have the thing you're extending pass you what you need
As you've more or less guessed, this (Having a global Kernel that becomes the dumping ground) is something that Ninject tries to dissuade you from. In general, the extension for whatever the you're using (e.g., MVC or WCF) will provide something if its appropriate. For example, the WCF extension has http://github.com/ninject/ninject.extensions.wcf/blob/master/source/Ninject.Extensions.Wcf/NinjectServiceHost.cs
The larger issue here is that dependencies like this should probably not propagate down to the Entity level - it should stay at the Service level and be propagated from there (using DDD vocabulary).
You may find this answer by me interesting as it covers this ground a bit (more from a Ninject techniques that an architectural concepts perspective)