ASP.NET MVC和ADO.NET实体框架

Question

我有一个问题，我无法解决没有一些建议。我正在开发一个ASP.NET MVC应用程序，并使用ADO.NET EF连接到数据库。我的问题是，我不知道我的应用程序的业务逻辑是否应该使用由EF创建的实体，或者是否应该创建一个抽象层并将EF实体与业务逻辑对象分开（并在这些对象类型之间开发一些转换器）。或者，也许我完全错了，我应该以不同的方式做？怎么样？哪种解决方案是最佳实践？

Answer 1

这绝对取决于您的应用程序，其范围和要求。仅仅为了层的目的而引入抽象层意味着引入复杂性和间接性，在这种情况下，它往往并不能真正帮助你。对于分层架构的过度使用，术语千层面软件目前正在引入 - 取代臭名昭着的意大利面条软件。

为了说明这一点，我不提议反抽象层。使用它们高度取决于您的具体要求。

我会从一个简单的体系结构开始，根据需要添加图层以确保可测试性和可维护性。当前版本实体框架（4.1截至发稿时）允许正与波苏斯和DbContext非常类似的工作模式库和单位。这些开箱即用的功能可能足以在大多数情况下启动。

Answer 2

我已经通过为Data类和Model类分开项目来处理类似的情况。

Data类将是由您的ADO.net模型生成的，然后您可以使用Repository模式连接到ADO.net上下文，检索数据类并使用类似http://automapper.codeplex.com/的东西来映射数据类到商业模式。

这将允许您在模型上使用MVC验证（例如Required，Regex等），并避免与Data类混淆，并且只传递模型。

Answer 3

一般来说，我最好将业务逻辑放在域模型和服务层中。领域模型中的逻辑是可取的，因为它更容易测试，但并不是所有的逻辑都很容易以这种方式实现。例如。当一个操作涉及许多域对象时，你不能总是合理地将它放在其中一个域中而不会影响性能和其他问题。

Answer 4

这是POCO发挥作用的地方。您可以从您的数据模型生成通用POCO，并将其用于业务层。 EF将创建POCO并跟踪它们。

的这里的想法是，你的POCO的只是实体，而不是EF对象（虽然EF确实，在幕后创建您POCO的代理版本）