ASP.NET MVC 和 ADO.NET 实体框架
我有一个问题，如果没有建议就无法解决。我正在开发 ASP.NET MVC 应用程序，并使用 ADO.NET EF 连接到数据库。我的问题是，我不知道我的应用程序的业务逻辑是否应该使用 EF 创建的实体，或者我应该再创建一个抽象层并将 EF 实体与我的业务逻辑对象分开（并在这些对象类型之间开发一些转换器）。或者也许我完全错了，我应该采取不同的做法？如何？哪种解决方案是最佳实践？
I have a problem that I cannot solve without some advice. I'm developing an ASP.NET MVC application and I'm using ADO.NET EF to connect to the database. My problem is that I don't know if business logic of my app should use entities created by EF or should I create one more abstraction layer and separate EF entities from my business logic objects (and develop some converters between those object types). Or maybe I'm totally wrong and I should do it differently? How? Which solution would be best practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这绝对取决于您的应用、其范围和要求。仅仅为了层而引入抽象层意味着引入复杂性和间接性，这通常不会真正让你有任何帮助。对于分层架构的过度使用，目前正在引入术语Lasagna Software - 取代臭名昭著的Spaghetti Software。
为了澄清这一点，我并不是反对抽象层。使用它们很大程度上取决于您的具体要求。
我将从一个简单的架构开始，然后根据需要添加层以确保可测试性和可维护性。当前版本的实体框架（撰写本文时为 4.1）允许使用 POCO，并且 DbContext 非常类似于存储库em> 和工作单元 模式。在大多数情况下，这些开箱即用的功能可能足以开始使用。
This absolutely depends on your application, its scope and its requirements. Introducing abstraction layers just for layers' sake means introducing complexity and indirection, where often it doesn't really get you anywhere. For the overuse of layered architecture the term Lasagna Software is currently being introduced - replacing the infamous Spaghetti Software.
To make this clear, I'm not proposing against abstraction layers. Using them just highly depends on your specific requirements.
I'd start with a simple architecture and add layers as required to ensure testability and maintainability. The current version Entity Framework (4.1 as of this writing) allows working with POCOs and the
DbContextpretty much resembles the Repository and Unit of Work patterns. These out-of-the-box features might be sufficient for a start in most cases.我已经通过为数据类和模型类建立单独的项目来处理类似的情况。
数据类将是由 ADO.net 模型生成的类，然后您可以使用存储库模式连接到 ADO.net 上下文，检索数据类，并使用类似 http://automapper.codeplex.com/ 将数据类映射到业务模型。
这将允许您在模型上使用 MVC 验证，例如必需的、正则表达式等，并避免弄乱数据类，并且仅传递模型。
I have handled situations like this by having separate projects for the Data classes and the Model classes.
The Data classes would be the ones generated by your ADO.net model, then you can use the Repository pattern to connect to the ADO.net context, retrieve the data classes, and use something like http://automapper.codeplex.com/ to map the data class to the business model.
This will allow you to use the MVC validation such as Required, Regex, etc on the models, and keep away from messing with the Data classes, and only pass around the Models.
一般来说，我发现最好将业务逻辑放置在域模型和服务层中。领域模型中的逻辑更可取，因为它更容易测试，但并非所有逻辑都可以轻松地以这种方式实现。例如，当一项操作涉及许多域对象时，您无法始终将其合理地放置在其中一个域对象中而不影响性能和其他问题。
In general, I find it best to place business logic both in the domain model, and in a service layer. Logic in the domain model is preferable, as it is easier to test, but not all logic is easily implemented in this way. E.g. when an operation involves many domain objects, you cannot always reasonably place it within one of them without performance implications and other issues.
这就是 POCO 发挥作用的地方。您可以从数据模型生成通用 POCO 并在业务层中使用它们。然后 EF 将创建 POCO 并跟踪它们。
这里的想法是，您的 POCO 只是实体，而不是 EF 对象（尽管 EF 确实如此，但在幕后创建 POCO 的代理版本）
This is where POCO's come into play. You can generate generic POCO's from your data model and use them in your business layer. EF will then create POCO's and track them.
The idea here is that your POCO's are just entities, and not EF objects (though EF does, behind the scenes create proxied versions of your POCO's)