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

        3层架构非常流行，但是它的真正含义是什么？ 表示层 应用层 数据库层 如果您问每层意味着什么，您可以肯定会得到几个不同的答案。您可以进一步将每一层划分为子层，并构建分层的地狱，例如： 客户端表示层 服务器侧视图层 控制器层 服务外观层 服务层 域对象层 仓库+工厂层 ORM层 存储过程层 数据库视图层 数据库表层 WTF？这只是示例，可以轻松地对应用程序进行架构设计。如果您坚持只有邻居可以交换数据，并且决定添加特殊类型的对象以在层之间交换，而不是让一组对象流过多个层，则情况可能更糟。 添加所需的层，使您更适应开发应用程序，并且可以合理分离关注点和应用程序规模所需的可维护性。您可以简单地执行最简单的应用程序，该应用程序将在数周内使用，并且必须尽快开发。在这种情况下，只需使用ASP.NET Web表单和数据源控件（或ASP.NET动态数据），您就可以在几天内完成此操作。它可能很难扩展，但在这种情况下，正是您快速实现应用程序所需要的。如果需要，编写层并围绕可维护性和可扩展性进行所有工作都是合理的。另一种快速原型技术是ASP.NET MVC支架，可以创建应用程序的快速多层框架，可以对其进行进一步修改。 两种方法都是正确的，并且仅取决于您喜欢的方法。第一种称为活动记录模式，但是它在实体框架中很少使用。第二种方法更受欢迎。您可以在称为“ 0”的中产阶级中直接使用EF（通用名称也为“ 1”）。此类将同时执行数据访问逻辑和业务逻辑。在更复杂的应用程序中，开发人员喜欢以某种方式将EF包装为遵循存储库模式的单独类，并从服务或直接从Web应用程序调用存储库。背后的代码或控制器（取决于业务逻辑的数量）。尝试先做而不使用存储库。我个人的观点是，人们只有在了解EF本身之后才应该开始使用存储库。 同样，两种方法都是正确的。在一个简单的应用程序中，完全可以使用POCO类（EFv4.x）创建EF模型并在所有层中使用它们。如果您使用的是ASP.NET MVC，则会发现您需要特殊的类作为视图模型来完全代表各个视图的需求。在更复杂的应用程序中，您可以从业务层公开单独的对象-如果业务层作为远程服务（WCF）公开，则尤其适用。 这取决于您如何编写这些DAL方法-绝对有必要在请求之间不共享EF上下文！这也取决于您是否要编写一些测试。静态方法定义的层与可测试的体系结构直接相反，在可测试的体系结构中，您只希望单层进行单元测试（使用EF进行单元测试可能很难）。它还取决于您是否要使用基于实例的依赖项注入。