2

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

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

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

我的问题：这不是将一些逻辑混合在一起吗？我的意思是我不应该使用特殊的视图模型类来表示，这些类应该有 UI 逻辑和验证？！

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

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

4

5 回答 5

2

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

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

于 2013-08-10T15:13:22.813 回答
1

您的问题需要大量讨论。

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

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

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

于 2013-08-11T14:35:29.370 回答
1

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

你可以开始阅读 Scott Millet Book

ASP.NET 设计模式

作为设计一个好的分层应用程序的起点，这里是他的博客。

于 2013-08-10T15:20:53.257 回答
1

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

问题是，考虑到单一职责，你的实体不应该担心 UI 的东西——这可能意味着你的接口也需要由“视图模型”类实现，这些类实现验证和其他业务和表示问题。

于 2013-08-10T15:21:00.223 回答
0

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

  • 型号 (POCO)
  • 数据访问 (NHibertante)
  • 服务（业务层）
  • 网页（用户界面）
    • 视图模型
于 2013-08-11T22:04:36.677 回答