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

Question

我正在创建一个Web应用程序并首先使用Entity Framework.我创建了实体数据模型,现在我不确定,现在该怎么办.

前提:我的数据库非常简单(Rating,WebPage,Visitor),数据库表对应于业务对象.

我的建议是3层架构,但如何制作呢？

1. 创建与Entity Framework对象同名的部分类(评级,访问者)并在此声明新方法(GetAverageRating()...)是个好主意？或者最好在这里创建一些VisitorProvider,RatingProvider和放置逻辑？

2. 最好在BLL和Presentation Layer中使用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 Scaffolding,它可以创建应用程序的快速多层骨架,可以进一步修改.

1. 这两种方法都是正确的,它只取决于您喜欢的方法.第一种称为活动记录模式,但它不经常用于实体框架.第二种方法更受欢迎.您可以直接在您调用的某个中间类中使用EF Provider(通用名也是Service).该类将同时执行数据访问逻辑和业务逻辑.在更复杂的应用程序中,开发人员喜欢以某种方式将EF包装到存储库模式之后的单独类中,并从服务或直接从Web应用程序调用存储库.代码隐藏或控制器(取决于业务逻辑的数量).首先尝试没有存储库.我个人的观点是人们应该在了解EF本身后才开始使用存储库.
2. 两种方法都是正确的.在一个简单的应用程序中,使用POCO类(EFv4.x)创建EF模型并在所有层中使用它们是完全可以接受的.如果您使用的是ASP.NET MVC,则可以发现需要使用特殊类作为视图模型来完全表示各个视图的需求.在更复杂的应用程序中,您可以从业务层公开单独的对象 - 如果业务层作为远程服务(WCF)公开,则尤其如此.
3. 这取决于你如何编写这些DAL方法 - 绝对有必要不在请求之间共享EF上下文!这也取决于你是否想要写一些测试.由静态方法定义的层直接针对可测试的体系结构,您希望单元测试只是单层(使用EF进行单元测试可能很困难).它还取决于您是否要使用基于实例的依赖注入.