asp.net-mvc - ASP.NET MVC - 服务层 - 业务层 - 数据层 (EF) - SQL DB::数据传输？

Question

我计划使用 ASP.NET MVC 作为 UI 层、WCF 作为业务层和 SQL DB 作为数据库来创建 3 层应用程序。

我的业务层将拆分为服务层 (WCF)、业务层(业务逻辑、业务模型)、数据层( Entity Framework - 数据库优先)。

数据层将使用 Entity Framework 的实体实现存储库方法，如 Get、GetById、Update、Insert。

业务层由业务规则及其模型组成。 (这是在 POCO 中)。

服务层只是将业务功能公开为可能的服务方法。

MVC 中的“M”只是表示模型 - Controller 使用它来将其转换为 JSON/XML 并将其提供给 View 或直接由 View 使用。

虽然上面提到的方法很常见，但如果这是一个好的设计，我仍然想确认它？

我真正的问题是关于层之间的数据传输(UI(MVC)-服务(WCF)-业务-数据层)

假设我启动了一个 GET 操作以从数据库中检索 Account 及其 Traits。在数据库中，它表示为两个不同的表。

帐户 --> 帐号、名称、类型

AccountTraits --> Id、AccountNumber、Category 等。

在 Datalayer 中，我想编写一个方法来获取给定的这两个表记录
使用 EF 的帐号。

我的业务模型有两个类，称为 Account 和 AccountTraits。
AccountTraits 的对象集合被聚合到 Account 类中。

像，

public class Account
{
    string AccountNumber;
    List<AccountTraits> Traits;
}

现在，如果我想用其数据填充这些域对象，我可以在我的数据层中使用如下所示的 EF 查询。

public IEnumerable<Account> GetAccountAndItsTraits(string AccountNumber)
{
var query = from a in db.Accounts
            select new Accounts() {
            AccountName = a.AccountName,
            Traits = from t in a.AccountTraits
            ....

return query;
}

这是从数据层 (EF) 填充业务模型 POCO 的常规方法吗？

现在，在应用了一些业务逻辑之后，我想将这些集合返回到 UI。如何将这些转移到服务层以及如何将其提供给 UI 模型？

我是否必须在 WCF 中使用确切的类定义定义 DataContract 作为业务模型，然后 “复制数据” 给它并把它交给用户界面？然后 UI 应该从 WCF 代理对象和 获取数据。 “复制到它的展示模型” (这又应该有自己的 Accounts 和 AccountTraits - 可能有一些额外的字段)？

如果您能对这些主题有所了解，那就太好了。

谢谢!

Answer 1

我绝对不会纯粹基于架构使用 WCF，除非您特别需要它提供的功能。 IE。某些传输/协议(protocol)以支持某些业务对业务的需求。 MVC 现在有了 WebAPI，它基本上与从 WCF 迁移的东西相同，并且更易于使用，并且可以满足您的架构需求而不会那么麻烦。

此外，我什至不会使用 WebAPI，除非我公开了一个我知道肯定会在我的应用程序之外使用的东西。如果这个服务层只会被这个 MVC 应用程序使用，那么我会取消它。您仍然可以拥有业务层 + 数据层并在没有它的情况下保持关注点分离。这只是我自己的看法。

通常我会使用 View 模型，它们是为 View 量身定制的模型。它们允许我独立地重构 View 或数据库，并且只需要更改数据转换代码。 IE。更改的数据库字段可能只需要在查询中进行调整，并且 ViewModel 保持不变，因此使用该 View 模型的所有 View 都保持不变。与查询实体并将其转换为 new Account 的方式几乎相同除了我将我的 AccountVM 命名为 View 模型( 模型 专门用于 View )

我个人从我的 Controller 中调用这些类型的数据查询/转换方法。然后 Controller 将 AccountVM 或集合传递给 View(vm)其中 vm 是保存 AccountVM 或集合的变量的名称。

这就是我将数据从 DB 获取到 View 的方式。无论如何，EF 实体类和 VM 类通常非常相似，有时甚至完全相同。我觉得中间业务实体类与一个或另一个过于相似，无法真正保证额外的类和额外的复制。

因此，在我看来，回答您的几个问题:
1 是的，基本上我认为这是一个很好的方法。

2 这个 GetAccountAndItsTraits 是从 Controller 调用的，而 View 是基于您的业务 poco(或者我称之为 ViewModel)的。因此，业务层的返回与您的模型所期望的相符。我不会在这里有服务层。但是，我可能有一些专门用于将 EF 实体转换为 View 模型的方法，这将在调用业务模型函数之后发生。换句话说，业务模型将返回 EF 实体，然后映射函数将这些实体映射到这种情况下所需的任何 View 模型，因为您可以拥有许多使用相同业务方法的 View 模型和 View 。我使用 EF Code First，所以我的实体类已经非常接近 POCO，所以它们泄漏到其他层并不会冒犯我。