c# - 实体数据框架和 Web 应用架构

Question

我正在创建一个 Web 应用程序并首先使用 Entity Framework。我创建了实体数据模型，现在我不确定如何继续。

前提:我的数据库非常简单(Rating、WebPage、Visitor)，数据库表与业务对象相对应。

我的建议是三层架构，但是如何实现呢？

1. 最好创建与 Entity Framework 对象(Rating、Visitor)同名的部分类，并在此处声明新方法(GetAverageRating()...)？还是创建一些 VisitorProvider、RatingProvider 并在此处放置逻辑更好？

2. 最好在 BLL 和表示层中使用 EF 对象，或者我应该在 BLL 层上创建自己的 BO 对象并将 EF 对象转换为 BO？

3. 我认为，在我的 DAL 上使用静态方法比在 BLL 上实例化类更实用。你同意？

你能给我推荐一些最佳实践吗？我有很多关于如何创建它的想法，但我不知道什么是正确的。

Answer 1

3 层架构非常流行，但它的真正含义是什么？

1. 表现层
2. 应用层
3. 数据库层

如果您询问每一层的含义，您可以肯定会得到几个不同的答案。您可以进一步将每一层划分为子层并构建分层 hell :

1. 客户端表示层
2. 服务器端 View 层
3. Controller 层
4. 服务门面层
5. 服务层
6. 领域对象层
7. 存储库+工厂层
8. ORM层
9. 存储过程层
10. 数据库 View 层
11. 数据库表层

WTF？这只是应用程序很容易过度架构的例子。如果您坚持只有邻居可以交换数据，并且如果您决定添加特殊类型的对象以在层之间交换而不是通过多个层流动单个对象集，情况可能会变得更糟。

添加您需要的层，让您更轻松地开发应用程序，并合理分离关注点和应用程序规模所需的可维护性。您可以简单地做最简单的应用程序，这些应用程序将在几周内使用，并且必须尽快开发。在这种情况下，您只需使用 ASP.NET Web 表单和数据源控件(或 ASP.NET 动态数据)即可在几天内完成。它的可扩展性可能很差，但在这种情况下，它正是您快速实现应用程序所需要的。如果需要，编写层并围绕可维护性和可扩展性做所有事情是合理的。另一种快速原型(prototype)制作技术是 ASP.NET MVC 脚手架，它可以创建可以进一步修改的应用程序的快速多层骨架。

1. 两种方法都是正确的，只取决于您喜欢哪种方法。第一个叫做 active record pattern但它并不经常与 Entity Framework 一起使用。第二种方法更受欢迎。您可以直接在您称为 Provider(常用名称也为 Service)的某个中间类中使用 EF。此类将执行数据访问逻辑和业务逻辑。在更复杂的应用程序中，开发人员喜欢以某种方式将 EF 包装到 repository pattern 之后的单独类中并从服务或直接从 Web 应用程序调用存储库。代码隐藏或 Controller (取决于业务逻辑的数量)。首先尝试在没有存储库的情况下进行。我个人的意见是，人们只有在了解 EF 本身后才应该开始使用存储库。
2. 同样，这两种方法都是正确的。在简单的应用程序中，完全可以接受使用 POCO 类 (EFv4.x) 创建 EF 模型并在所有层中使用它们。如果您使用的是 ASP.NET MVC，您会发现您需要特殊的类作为 View 模型来完全表示您的各个 View 的需要。在更复杂的应用程序中，您可以从业务层公开单独的对象 - 这在业务层作为远程服务 (WCF) 公开时尤其有用。
3. 这取决于您如何编写这些 DAL 方法 - 它是 absolutely necessary to not share the EF context among requests !这也取决于您是否要编写一些测试。由静态方法定义的层是直接反对可测试架构的东西，在可测试架构中，您希望仅对单层进行单元测试(使用 EF 进行单元测试可能很困难)。它还取决于您是否要使用基于实例的依赖注入(inject)。