logo标签列表

ASP.NET MVC和ADO.NET Entity Framework

asp.net-mvcentity-frameworkado.net-entity-data-model
3

我有一个问题，需要一些建议来解决。我正在开发一个ASP.NET MVC应用程序，并使用ADO.NET EF连接数据库。我的问题是，我的应用程序的业务逻辑是否应该使用EF创建的实体，还是应该创建一个更抽象的层次，将EF实体与我的业务逻辑对象分离（并开发一些转换器来转换这些对象类型）。或者也许我完全错了，应该以不同的方式处理？如何处理？哪种解决方案是最好的实践？

4个回答
2
这完全取决于您的应用程序、其范围和要求。仅为了引入抽象层而引入抽象层意味着引入复杂性和间接性，而往往并没有实际作用。对于分层架构的过度使用，目前正在引入一个术语“千层饼软件”——取代臭名昭著的“意大利面条软件”。
要明确这一点，我并不反对抽象层。它们的使用高度取决于您的具体要求。
我会从简单的架构开始，并根据需要添加层以确保可测试性和可维护性。当前版本的Entity Framework（截至本文撰写时为4.1）允许使用POCO和DbContext，几乎类似于Repository和Unit of Work模式。这些开箱即用的功能在大多数情况下可能已经足够了。
谢谢你的回答。你的帖子让我受到了启发，提醒我要“睁大眼睛” :) - TrN
很高兴能帮忙！我知道自己有多容易陷入分析瘫痪的状态... - Dennis Traub
0

我处理这种情况的方法是为数据类和模型类分别创建不同的项目。

数据类将由您的 ADO.net 模型生成，然后您可以使用存储库模式连接到 ADO.net 上下文，检索数据类，并使用类似于 http://automapper.codeplex.com/ 的工具将数据类映射到业务模型。

这将允许您在模型上使用 MVC 验证，例如必填项、正则表达式等，并避免与数据类混淆，只传递模型。

0
通常，我发现将业务逻辑放在域模型和服务层中是最好的选择。将逻辑放在域模型中更可取，因为它更容易进行测试，但并不是所有逻辑都可以以这种方式轻松实现。例如，当一个操作涉及许多域对象时，你不能总是合理地将其放在其中一个对象中，否则会有性能问题和其他问题。
0
这就是POCO的作用所在。您可以从数据模型中生成通用的POCO，并在业务层中使用它们。EF将创建POCO并跟踪它们。
这里的想法是，您的POCO只是实体，而不是EF对象（尽管EF在幕后创建了代理版本的POCO）。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接