8

我正在将旧版 Web 窗体应用程序扩展/转换为全新的 MVC 应用程序。扩展既是技术方面的，也是业务用例方面的。遗留应用程序是一个完善的数据库驱动设计 (DBDD)。因此，例如，如果您有不同类型的员工，如操作员、主管、商店管理员等，并且您需要添加一个新类型，您只需在几个表中添加一些行，瞧，您的 UI 会自动添加所有内容/更新新类型的员工。然而，层的分离不是那么好。

新项目有两个主要目标

  • 可扩展性（针对当前和未来的管道要求）
  • 表现

我打算创建一个新项目，用域驱动设计 (DDD) 替换数据库驱动设计 (DBDD)，同时牢记可扩展性要求。然而，如果我将它与传统 DBDD 应用程序的性能进行比较，从数据库驱动设计转向领域驱动设计似乎会对性能要求产生负面影响。在遗留应用程序中，任何来自 UI 的数据调用都将直接与数据库交互，并且任何数据都将以 DataReader 或（在某些情况下）DataSet 的形式返回。

现在有了严格的 DDD，任何数据调用都将通过业务层和数据访问层进行路由。这意味着每次调用都会初始化一个业务对象和一个数据访问对象。单个 UI 页面可能需要不同类型的数据，这是一个 Web 应用程序，每个页面都可以由多个用户请求。此外，一个 MVC Web 应用程序是无状态的，每个请求都需要每次都初始化业务对象和数据访问对象。因此，对于 MVC 无状态应用程序而言，DBDD 似乎比 DDD 性能更可取。

或者在 DDD 中有一种方法可以同时实现 DDD 提供的可扩展性和 DBDD 提供的性能？

4

3 回答 3

6

您是否考虑过某种形式的命令查询分离，其中更新通过域模型但读取来自 DataReaders？成熟的 DDD 并不总是合适的。

于 2012-05-21T12:05:51.057 回答
4

“现在有了严格的 DDD，任何数据调用都将通过业务层和数据访问层进行路由。”

我不相信这是真的，当然也不实用。我相信这应该是：

现在有了严格的 DDD，任何对事务的调用都将通过业务层和数据访问层进行路由。

没有什么说您不能直接调用数据访问层来获取您需要在屏幕上显示的任何数据。只有当您需要修改数据时，您才需要调用基于其行为设计的域模型。在我看来，这是一个关键的区别。如果您通过域模型路由所有内容，您将遇到三个问题：

  1. 时间 - 实现功能会花费您更长的时间，但没有任何好处。
  2. 模型设计——你的领域模型会变形，以满足查询而不是行为的需要。
  3. 性能 - 不是因为额外的层，而是因为您无法像直接从查询中那样快速地从模型中获取聚合数据。即考虑为特定客户下达的所有订单的总价值——为此编写查询比获取客户的所有订单实体、迭代和求和要快得多。

正如 Chriseyre2000 所提到的，CQRS 旨在解决这些确切的问题。

于 2012-05-25T10:51:16.400 回答
1

在您的场景中，使用 DDD 应该不会对性能产生重大影响。您担心的似乎更像是数据访问问题。你把它称为

初始化业务对象和数据访问对象

为什么“初始化”很昂贵？您使用什么数据访问机制？

存储在关系数据库中的长寿命对象的 DDD 通常使用 ORM 实现。如果使用得当，ORM 对大多数应用程序的性能影响很小（如果有的话）。如果存在已证实的瓶颈，您始终可以将应用程序中对性能最敏感的部分切换回原始 SQL。

对于它的价值，NHibernate 只需要在应用程序启动时初始化一次，之后它使用与常规数据读取器相同的 ADO.NET 连接池。因此，这一切都归结为正确的映射、获取策略和避免典型的数据访问错误，如“n+1 选择”。

于 2012-05-23T03:51:10.000 回答