EF 代码优先如何在客户端层中使用 POCO 对象

Question

我是asp.net MVC 和EF 的新手，如果我的问题不清楚或不简单，请原谅。

我已经阅读了一些关于 EF Code-First 方法的教程，现在我正在尝试这个教程Getting Started with EF using MVC。

使用 Code-First 方法我正在使用 POCO 类来定义我的数据库模型、数据库逻辑、数据库验证、UI 验证和一些 UI 逻辑。因此，我可以在表示层中使用这些类（或对象），或者在处理 Web 服务（或 JavaScript 代码）时将它们用作 JSON 对象。

我的问题：这不是将一些逻辑混合在一起吗？我的意思是我不应该使用像 special 视图模型类进行演示，这些类应该具有 UI 逻辑和验证？！

将 POCO 对象发送到视图（或一般客户端）是一种好习惯吗？

最后我需要一些关于如何组织我的项目layers或folders的指导吗？我看到了很多方法，但我对选择什么或我应该基于什么格式感到困惑？！！

Answer 1

您不应在应用程序的较高层中使用数据实体。使用 Automapper 等库将数据从 DAL 转换/组合/复制到视图模型或业务类。这使您的应用程序的各个层保持独立，并对最终用户隐藏您的数据库架构。

请记住，MVC 只关心演示，所有实际工作都应该发生在应用程序的其他层中。我尝试保持图层独立，并使用一点胶水代码将它们捆绑到应用程序中。在处理 MVC 项目时，我可能会编写数据访问和业务逻辑层，然后在命令行实用程序中重新使用。有很多书都在谈论编写高质量的代码。我个人发现Clean Code、Code Complete 2 和Design Patterns 非常有帮助。

Answer 2

正如 LeffeBrune 所说，直接向表示层显示数据实体是不好的做法，您可以尝试以项目服务的形式公开一些接口，将视图模型返回给控制器。这有助于保持层分离，并实现工作单元模式和其他一些很酷的东西。

你可以开始阅读 Scott Millet 书了

ASP.NET 设计模式

如需了解如何设计一个好的分层应用程序，请here他的博客。

Answer 3

您可以在您的业务层中定义您的 EF 实体可以实现的接口；业务逻辑不知道实际的实现。为此，您需要 数据层 来引用 业务层，这意味着您正在反转依赖关系 - 然后您使用 IoC 容器将接口绑定到它们的实现。 ...但是，是的，这是众多方法中的一种。

问题是，考虑到单一职责，您的实体不应该担心 UI 的东西 - 这可能意味着您的界面还需要由实现事物的“视图模型”类实现例如验证以及其他业务和演示问题。

Answer 4

您的问题需要大量讨论。

为您的项目选择基础架构是一个复杂的问题，取决于很多因素。有一些设计模式可以解决项目中的不同要求，这些要求涉及您或您的团队涉及多种概念和技术。我向您推荐两个有价值的资源，可帮助您了解专注于 .Net 技术的软件架构。

1. CSLA.NET：CSLA .NET 框架是一个应用程序开发框架，可降低构建和维护应用程序的成本。 CSLA.NET 的创建者 Rockford Lhotka 有一些书籍深入描述了项目的最佳基础架构；你的所有问题都在他的书中得到了解答。
2. Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App：项目/示例被故意限制为基于易于理解的简单场景（客户、订单、银行转账等）的 N 层面向领域架构中最常用模式的 .NET 实现。该项目/示例有很好的文档记录，您的所有问题也已在项目中得到解答。

总而言之，视图模型、POCO、层等都是根植于软件架构的概念，我认为它们不能简单描述。

Answer 5

正如 LeffeBrune 所说，我通常使用的是在我的数据访问中使用的 POCO 层和在我的视图中使用的视图模型层。 我所有的层都使用 POCO，控制器负责构建每个视图所需的视图模型。 为了让这项工作更加自动化，我使用了 automapper。 所以我的解决方案结构通常是这样的：

• 型号 (POCO)
• 数据访问 (NHibertante)
• 服务（业务层）
• 网页（用户界面）
  • 视图模型