5

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

我的业务层将拆分为服务层 (WCF)、业务层（业务逻辑、业务模型）、数据层（实体框架 - 数据库优先）。

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

  • 业务层由业务规则及其模型组成。（这是在 POCO 中）。

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

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

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

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

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

  • 帐户 --> 帐号、名称、类型
  • AccountTraits --> Id、AccountNumber、Category 等。

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

我的业务模型有两个类，称为 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;
}

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

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

  3. 我是否必须在 WCF 中使用确切的类定义将 DataContract 定义为业务模型，然后将数据“复制”到它并将其提供给 UI？那么 UI 应该从 WCF 代理对象获取数据并“复制到它的表示模型”（它应该有自己的 Accounts 和 AccountTraits - 可能带有一些额外的字段）？

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

谢谢！

4

1 回答 1

3

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

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

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

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

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

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

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

于 2012-11-13T07:03:18.743 回答