我可以看到如何使用 autofac 实例化类的对象，然后将它们传递给 db4o 进行存储。当我需要从 db4o 检索对象实例时，如何使用 autofac 注册对象？
我最初计划使用 db4o 的 MSBuild 工具来实现透明的激活/持久性，但看起来我可能必须为所有 Model 对象手动实现 IActivatable 接口，以便我可以在 IActivatable:: 中添加额外的代码Bind() 在激活时注册 this 指针。
更糟糕的是，我预见 IActivatable::Bind() 的实现将必须访问当前 Autofac 生命周期范围的 Singleton 来进行注册。显然，我无法将当前生命周期范围传递给 db4o 正在激活的对象实例。就像传递范围一样糟糕，我可以想象那些考虑将当前生命范围保留在公共单例中的人们的抱怨。
另一种选择似乎是实现 db4o 的类型处理程序并在此时拦截对象实例化，但这似乎抵消了我使用 db4o 存储对象所获得的任何收益。
或者我只是对使用 autofac 实例化所有对象的想法有点太疯狂了？ （例如，我有一把锤子，而所有东西看起来都像钉子。） Model 对象是否应该仅通过普通的旧“新”以及 db4o 使用的任何魔法来实例化？换句话说，仅对我的 View、ViewModel 和 Controller 对象使用 autofac。
I can see how I can instantiate objects of classes using autofac, and then pass these to db4o for storage. When it's time for me to retrieve the object instances from db4o, how do I register the objects with autofac?
I was originally planning on using db4o's MSBuild tool to implement transparent activation/persistence, but it looks like that I may have to manually implement the IActivatable interface for all my Model objects so that I can put in extra code in IActivatable::Bind() to register this pointers as they are activated.
To make matters worst, I foresee that the implementation of IActivatable::Bind() will have to access a Singleton of the current Autofac lifetime scope to do the registration against. Obviously, I can't pass in the current lifetime scope to the object instance that db4o is activating. As bad as passing the scope around is, I can imagine the groans from people considering sticking the current life scope in a public Singleton.
An alternative seems to be to implement db4o's Type Handlers and intercept object instantiation at that point, but that seems like undoing any gains I had of using db4o for storing objects.
Or did I just go a little too crazy with the idea of using autofac to instantiate all objects? (e.g. I've got a hammer and everything looked like a nail.) Should Model objects just be instantiated by plain old 'new' and whatever magic that db4o uses? In other words, use autofac only with my View, ViewModel and Controller objects.
发布评论
评论（2）
没有“真正的路径”:)，但这里推荐的方法是避免直接在域模型中使用服务，而是将“域事件”分派给支持 IoC 的处理程序。
Jimmy Bogard 在该主题上发表了大量帖子 - 有一个 StructureMap 示例，您应该能够适应 Autofac：http://lostechies.com/jimmybogard/2010/08/04/container-friend-domain-events/
（顺便说一句，巧合的是，我有一个基于 Autofac 的示例实现，我'我正在清理并在接下来的几周内发布。）
There's no "true path" :) but the recommended approach here is to get away from using services directly in the domain model, and instead dispatch 'Domain Events' to IoC-enabled handlers.
Jimmy Bogard has a good number of posts on the topic - there's an example for StructureMap that you should be able to adapt for Autofac: http://lostechies.com/jimmybogard/2010/08/04/container-friendly-domain-events/
(BTW, coincidentally, I have an Autofac-based example implementation that I'm cleaning up to release in the next few weeks.)
我建议用 Autofac 实例化替换每个“新”。我的经验法则是，当一个对象需要复杂的依赖项（不是简单的集合、核心 CLR 类型、其他简单对象）时，我会让 Autofac 来做这项工作。简单的域对象我通常只使用 new 运算符或创建工厂。
我不能 100% 确定我是否正确回答了你的问题。您想在实例化某些服务时将其绑定到域模型吗？那么我建议使用 事件。您可以使用 db4o 事件来检测对象何时被存储、激活等。在此类事件侦听器中，您可以使用当前 Autofac 作用域来传递其他服务。
顺便提一句。 IActivatable::Bind() 已经被 db4o 调用。您不需要做任何其他事情。
一般来说，我会尝试正确确定所有内容的范围，而不是滥用 Autofac 作为服务定位器。
I would recommend to replace every 'new' with an Autofac instantiation. My rule of thumb is that I when a object needs complex dependencies (not simple collections, core CLR types, other simple objects), then I let Autofac do the work. Simple domain object I usually just use the new operator or a create a factory.
I'm not 100% sure if I get your question right. You want to bind some service to your domain models when they are instantiated? Well then I recommend to use events. You can use the db4o events to detect when an object gets stored, activated, etc. In such a event listener you can use the current Autofac scope to pass additional services.
Btw. the IActivatable::Bind() stuff is already called by db4o. You don't need to do anything else.
In general I would try to properly scope everything and not misuse Autofac as a service-locater.