实体数据框架和Web应用程序体系结构

Question

我正在创建一个Web应用程序并首先使用实体​​框架。我创建了实体数据模型，现在我不确定，现在该怎么做。

前提：我的数据库真的很简单（Rating，WebPage，Visitor）和数据库表对应的业务对象。

我的建议是3层架构，但如何使它？

1. 这是好主意，创造局部类具有相同的名称作为实体框架对象（评级，访问者），并在这里宣布新方法（GetAverageRating（）...）？或者更好地创建一些VisitorProvider，RatingProvider和放置逻辑？

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

3. 我想，这是更实际的使用我的DAL静态方法比在BLL上实例化类。你同意吗？

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

Answer 1

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

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

如果你问什么每层意味着你可以确信你会得到几个不同的答案。您还可以将每个层为底层，并建立分层地狱一样：

1. 客户端展现层
2. 服务器侧视图层
3. 控制器层
4. 服务门面层
5. 服务层
6. 域对象层
7. 存储库+工厂层
8. ORM层
9. 存储过程层
10. 数据库视图层
11. 数据库表层

WTF？这只是应用程序可以轻松架构的例子。如果你坚持只有邻居可以交换数据，并且你决定添加特殊类型的对象才能在层间交换，而不是通过多层对象流动唱歌，那么情况会更糟。

添加您需要的图层，使其更加适合开发应用程序，并且可以合理区分应用程序规模所需的关注点和可维护性。您可以简单地做最简单的应用程序，只需几周即可使用，并且必须尽快开发。在这种情况下，只需使用ASP.NET Web窗体和数据源控件（或ASP.NET动态数据），即可在几天内完成此操作。它可能是非常可扩展的，但在这种情况下，它正是您快速实现应用程序所需的东西。如果您需要它，编写图层并在可维护性和可扩展性方面做所有事情是合理的。另一种快速原型技术是ASP.NET MVC脚手架，它可以创建可以进一步修改的应用程序的快速多层骨架。

1. 两种方法都是正确的，它只取决于你喜欢的方法。第一个称为active record pattern，但它并不经常用于实体框架。第二种方法更受欢迎。你可以直接在一些中产阶级中使用EF，这些产品叫做Provider（通用名也是Service）。这个类将执行数据访问逻辑和业务逻辑。在更复杂的应用程序开发者喜欢以某种方式将EF包装到分开的类repository pattern后，并从服务或直接从Web应用程序调用存储库。后面的代码或控制器（取决于业务逻辑的数量）。尝试在没有存储库的情况下先做。我个人认为，只有当他们了解EF本身时，人们才应该开始使用存储库。
2. 这两种方法都是正确的。在一个简单的应用程序中，完全可以使用POCO类（EFv4.x）创建EF模型并在所有图层中使用它们。如果您使用的是ASP.NET MVC，则可以发现您需要特殊的类作为视图模型，以充分表示您的各个视图的需求。在一个更复杂的应用程序中，您可以使用从业务层公开的单独对象 - 如果业务层作为远程服务（WCF）公开，则尤其如此。
3. 这取决于你如何编写这些DAL方法 - 它是absolutely necessary to not share the EF context among requests！这也取决于你是否想写一些测试。由静态方法定义的层是直接针对可测试体系结构的地方，您希望单元测试只是单层（使用EF进行单元测试可能很困难）。它也取决于你是否想使用基于实例的依赖注入。