关于 MVC3 和存储库模式的建议EF
我与另一位开发人员讨论了 mvc3 和 EF 的存储库模式，这让我感到非常困惑。
我不确定将存储库模式与 MVC3 和 EF 结合使用时应遵循的最佳实践。
假设我有一个名为 Product 的表，其中包含 ProductID 和 ProductID。产品名称。我创建了新的 EF 模型。 我还创建了一个基本模型 ProductModel
public int ProductID{get;set:}
public string ProductName{get;set}
我的控制器是否应该了解有关 EF 创建的实体的任何信息？或者我是否打算在我的存储库中与 EF 进行所有对话？
例如，基本帖子
[HttpPost]
public ActionResult Product(ProductModel model)
然后在我的控制器中，我将模型传递到我的存储库以处理插入，或者我的控制器应该直接绑定到我的 EF 产品模型，然后将其传递到我的存储库以处理插入。
我认为使用存储库的想法是，假设在 12 个月内，如果我想剥离实体框架并使用其他东西，我只需要更新我的存储库，而不必触及任何控制器。
最佳实践是什么？
I had a discussion with another developer regarding the repostory pattern with mvc3 and the EF that has gotten me sightly confused.
I am not sure the best practice to follow using the repository pattern with MVC3 and the EF.
Lets say I have a table called Product containing ProductID & ProductName. I create my new EF model.
I also create a basic model ProductModel
public int ProductID{get;set:}
public string ProductName{get;set}
Should my controller know anything about my entity created by the EF? or am I meant to be doing all my talking to the EF inside my repository?
e.g. A basic post
[HttpPost]
public ActionResult Product(ProductModel model)
Then in my controller, I pass the model to my repository to take care of the insert or should my controller be bound to directly to my EF Product Model and then pass that to my repository to take care of the insert.
I thought the idea of the using the repository is that lets say in 12 months time if I wanted to stripe out the entity framework and use something else I would only need to update my repository and wouldn't have to touch any of my controllers.
What is the best practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您想在一段时间后
剥离实体框架而不更改控制器，则需要使用存储库模式将持久性逻辑与 UI 分开。另外，不要使用模型类作为 MVC 层的视图
models。您可以将单独的视图模型用于 UI 逻辑，并使用 AutoMapper 之类的东西（ http://automapper.codeplex.com/ ) 来映射模型类。If you wan to
stripe out the entity frameworkafter some time withoud changing Controller you need to use repository pattern to separate persistence logic from UI.And additionally don't use model classes as view
modelsfor the MVC layer.You can use separated view models for UI logic and Use something like AutoMapper ( http://automapper.codeplex.com/ ) to map with model classes .你的最后一段完美地总结了这一点。
您希望使用接口驱动开发，以便您的控制器能够处理
IProductRepository。使用依赖项注入将具体的实体框架存储库注入到控制器中。
正如 @Jayantha 提到的，您的
[HttpPost]操作应该接受 ViewModel，而不是 EF 模型。然后使用 AutoMapper 在 ViewModel 和 EF 模型之间进行映射。
存储库将 EF 逻辑包装在一处（保存、删除、更新等），因此您的控制器保持简单和愚蠢。
保持你的接口尽可能简单和精简，那么如果/当你切换到新的实现时，只要新的实现能够符合接口规范，那么你的Controller就不需要改变，只需要改变依赖注入配置。
Your last paragraph sums it up perfectly.
You'd want to use interface-driven development, so that your Controller's deal with a
IProductRepository.Use dependency injection to inject a concrete Entity Framework repository into the Controller.
As @Jayantha mentions, your
[HttpPost]action should accept a ViewModel, not the EF model.Then use AutoMapper to map between the ViewModel and the EF model.
The repository will wrap EF logic in one place (Save, Delete, Update, etc), so your Controller stays simple and dumb.
Keep your interface as simple and as thin as possible, then if/when you switch over to the new implementation, as long as the new one can conform to the interface specification, then your Controller's need not change, only the dependency injection configuration.
我更喜欢使用 Dev Magic Fake，使用 Dev Magic Fake 你不需要使用 EF 或考虑任何事情，你只需要添加对 Dev Magic Fake 程序集的引用并开始使用魔法方法
有关更多信息，请参阅 CodePlex 上的 Dev Magic Fake
< a href="http://devmagicfake.codeplex.com" rel="nofollow">http://devmagicfake.codeplex.com
谢谢
拉德万
I prefer use Dev Magic Fake, with Dev Magic Fake you don't need to use EF or consider anything, you just need to add reference to Dev Magic Fake assembly and start using the magic methods
For more information see Dev Magic Fake on CodePlex
http://devmagicfake.codeplex.com
Thanks
M.Radwan