将存储库模式与 EF 4.1 数据库优先方法结合使用
这可能吗？
有例子吗？到目前为止，我的搜索已证明毫无结果...
我使用这种方法的原因是因为我必须坚持使用 MVC 3 应用程序的旧数据库，但有一些相当复杂的关联和继承层次结构，因此我希望 EF 生成映射而不是我手动完成。我想使用存储库模式进行单元测试。 任何建议表示赞赏。
Is this possible?
Are there any examples? My searches have proved fruitless so far...
The reason I am using this approach is because I have to stick with a legacy database for my MVC 3 app but there are some quite complex associations and inheritance hierarchies so I want EF to generate the mappings instead of me doing it manually. I want to use the Repository pattern for unit testing.
Any advice appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您只搜索“存储库模式实体框架 4.1”或其他内容并忘记术语“数据库优先”，您的搜索将会富有成效。手动编写类（代码优先）或通过 DbContext 生成器（数据库/模型优先）生成它们并不重要。最后您的存储库将使用这些类。没有生成器可以为您编写有意义的存储库 - 除了模型的 DbSet 之外，它们是通用存储库的专业化。您必须根据模型类和您的业务需求手动编写它。
因此，无论您遵循代码优先还是数据库/模型优先方法，都不会影响存储库的设计。
关于使用 EF 和单元测试的存储库模式，我建议将此作为警告和起点阅读，并遵循该答案中的大量链接：
具有实体框架 4.1 和父/子的存储库模式关系
Your search will become fruitful if you just search for "Repository pattern Entity Framework 4.1" or something and forget the term "Database First". It doesn't matter if you write your classes by hand (Code First) or generate them through the DbContext Generator (Database/Model First). In the end your repository will use those classes. There is no generator which would also write a meaningful repository for you - aside from the
DbSets of your model which are specializations of a generic repositories. You must write it by hand based on the model classes and your business needs.So, it doesn't affect the design of a repository whether you follow a Code First or Database/Model First approach.
About repository pattern with EF and unit testing I recommend to read this as a warning and starting point and follow the plenty of links in that answer:
Repository Pattern with Entity Framework 4.1 and Parent/Child Relationships
如果您愿意，您仍然可以使用代码优先样式：代码优先允许您从现有数据库进行逆向工程以开始使用。或者，如果您已经有 EDMX，则可以使用 T4 模板（包含 EF 4.1）生成代码优先类。或者，再次使用 T4 模板生成 POCO 并保持数据库优先作为策略。
但我认为即使采用数据库优先的风格，您仍然可以轻松实现存储库模式。我认为你的主要问题将在于对某些实体框架 DLL 的依赖（如果你这样做的话）（你可以认为这不是问题）。
You could still use Code-first style if you want : code-first lets you reverse-engineer from an existing database to get you started. Or if you already have an EDMX, you can generate your code-first classes with a T4 template (packed with EF 4.1). Or, again, use T4 templates to generate POCOs and keep database-first as a strategy.
But I think you could still easily achieve a repository pattern even with database-first style. I think your main problem will be in the dependance to some entity framework DLLs if you do (which you could decide is not a problem).
我知道这篇文章晚了一天，而且可能还差一美元。但到目前为止，我很幸运，通过在控制器中创建 DbContext 实例并将其传递到我的存储库实例中，在数据库优先上实现存储库模式。然后，我确保存储库中的方法在必要时返回我的对象的类型。
以这种方式使用存储库时，我遇到了两个主要问题。
首先，我的控制器上的默认 Dispose 方法存在问题。由于我在存储库中调用 DbContext，因此我必须继承 IDisposable 并在那里实现 Dispose 方法。
我使用本教程作为示例
http://csharppulse.blogspot.in/ 2013/09/learning-mvc-part-6-generic-repository.html
我遇到的下一个问题是更新我的对象时。
因为我已经传入了 DbContext，所以我的对象已经存在。所以我必须用逻辑来设计我的更新方法，看看它是否已经存在。
我用这篇文章来帮助解决这个问题
具有相同键的对象已存在于 ObjectStateManager 中。 ObjectStateManager 无法跟踪具有相同键的多个对象
I know this post is a day late and probably a dollar short. But I've had good luck so far implementing Repository Pattern on Database First by creating an instance of my DbContext in my controller and passing it into my Repository instance. Then I made sure my the methods in my Repositories return the Type of the my object when necessary.
I ran into two main issues while using Repository in this fashion.
Firstly I had an issue with the default Dispose method on my controllers. Since I was calling the DbContext in my Repository, I had to inherit IDisposable and implement the Dispose method there.
I used this tutorial as an example of that
http://csharppulse.blogspot.in/2013/09/learning-mvc-part-6-generic-repository.html
The next issue I ran into was when it came time to update my objects.
Because I had passed in the DbContext, my objects already existed. So I had to fashion my update method with logic that looked to to see if it already existed.
I used this article to help with that
An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same key