Entity Framework 4 - 在生成的实体中嵌入 ObjectContext 引用
我是 Entity Framework 4.0 的新手，将其与 C# 一起使用，目前正在尝试其功能。
我注意到，与大多数类似的 ORM 一样，它依赖于 Context 对象来处理在生成的实体上完成的数据操作和 CRUD 语句生成。
这意味着，如果我想将更改保存回数据库，我始终需要能够访问对已实例化实体的 ObjectContext 的引用。
如果上下文是在可访问的范围内创建的（例如，相同的方法），那很好，但是如果我将一个实体或实体集传递给一个方法并希望该方法保存更改，该怎么办？看起来唯一简单的方法是将 ObjectContext 与参数一起传递。
另一种解决方案是将 ObjectContext 放置在某种全局变量中。 不用说，我发现这两种方法都存在样式和可维护性问题。
简而言之，我能想到的最好方法是从实体或实体集中获取对 ObjectContext 的引用。 我知道默认情况下这是不可能的。
我找到了一种方法，显示添加扩展方法以从实体获取 ObjectContext。然而，它仅适用于具有关系的实体，并且根据作者的说法，调用此方法的成本很高。
我正在考虑修改 T4 模板以将 Context 属性添加到我的所有实体并在实体实例化时自动填充它。
我已经修改了一次 T4 模板，让实体框架在生成的类上强制执行最大长度（按照 Julie Lerman 的《编程实体框架 4》一书）。 到目前为止，我不能说我真的很喜欢 T4 语法，但如果这是最好/唯一的方法，那就这样吧...
是否有人已经这样做了，处理这个问题的最佳方法是什么，并愿意分享他的 T4模板或解释什么是最好的部分方法或事件来完成这项工作？
使用这种方法有什么重大缺点吗？ 我认为，如果我的某些实体仍在范围内，但实际上我不再使用 ObjectContext，那么对 ObjectContext 进行如此多的引用可能会阻碍/延迟 GC 重新收集它的能力。
非常感谢。
I am new to Entity Framework 4.0, using it with C#, and currently experimenting with its features.
What I noticed is that, like with most similar ORMs, it relies on an Context object to deal with the data-manipulation and CRUD statements generation done on the generated entities.
This means that if I want to save the changes back to the database, I always need to be able to have access to a reference to the ObjectContext that has instanciated the entities.
It is fine and all if the context has been created in an accessable scope (same method, for example), but what if I pass an entity or and entity set to a method and want this method to save the changes? It looks like the only easy way is to pass the ObjectContext along with the parameters.
Another solution would be placing the ObjectContext in some sort of global variable.
Needless to say, I find styling and maintainability issues to both of these approaches.
In short, the best way I can imagine is getting a reference to the ObjectContext from the entity or entity set.
I know that it isn't possible by default.
I have found a method showing adding an extension method to get the ObjectContext from the entity. However, it only works for entities with relationships and calling this method is expensive according to the author.
I was thinking about maybe modifying the T4 template to add a Context property to all my entities and fill it automatically on entities' instanciation.
I have already modified T4 template once to have Entity Framework enforce Max Length on my generated classes (by following Julie Lerman's Programming Entity Framework 4 book).
I can't say I really enjoy the T4 syntax so far, but if that's the best/only way, so be it...
Has anyone already done so and what would be the best way to handle this and willing to share his T4 template or explain what are the best partial methods or events to hook into to get this done?
Is there any major downside in using such an approach?
I am thinking that having so many references to the ObjectContext may hinder/delay its ability to be recollected by the GC if some of my entities remain in scope but I actually have no use anymore for the ObjectContext.
Many thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您需要将对象上下文作为参数与实体一起传递，那么您就做错了。
通常只有在明确定义的层中才需要上下文。该层的所有逻辑需要上下文的类都可以通过一些专门的类 - 上下文提供者（也可以称为服务定位器）接收上下文。上下文提供程序将在某个存储中保存当前上下文实例 - 您可以创建自己的上下文实例，也可以按线程、每个 http 请求等存储它。
如果他们在您的类中需要多个上下文实例，您可以修改您的提供程序以使其也可以作为工厂。
另一种常见的方法是与依赖注入相结合。您将通过构造函数（或属性）将上下文传递给您的类，并且您将拥有一些引导程序代码，它将为您执行所有必要的初始化（创建所需的实例并将所有依赖项传递给它们）。同样，您可以传递上下文或工厂。它通常与 IoC 容器一起使用，后者将为您完成管道工作。
一旦准备好这个基础设施，您就可以将实体传递给该层中的任何初始化类，并且它将具有可用的上下文。
If you need to pass object context as parameter together with your entities you are doing something wrong.
Usually context is needed only in well defined layer. All classes from this layer which requires context to their logic can receive the context through some specialized class - context provider (it can also be called service locator). Context provider will hold current context instance in some storage - you can create your own or you can store it per thread, per http request, etc.
If they need more then one context instance in your classes you can modify your provider to work also as factory.
Another common approach is combined with dependency injection. You will pass the context to your classes through the constructor (or property) and you will have some bootstraper code which will do all necessary initialization for you (create required instances and pass all dependencies into them). Again you can pass a context or a factory. This is usually used together with IoC containers which will do the plumbing for you.
Once you have this infrastructure prepared you can pass your entity to the any initialized class from that layer and it will have the context available.