您更喜欢哪一个来搜索/报告 DataTable 或 DTO 或域类？答案

【问题标题】：Which one do you prefer for Searching/Reporting DataTable or DTO or Domain Class?您更喜欢哪一个来搜索/报告 DataTable 或 DTO 或域类？
【发布时间】：2008-12-25 13:34:30
【问题描述】：

我目前从事的项目需要大量搜索/过滤页面。例如，我有一个复杂的搜索页面来按数据、类别、单位、...获取问题。

问题域类很复杂，包含大量的值对象和子对象。

。我想知道人们如何处理 UI 的搜索/过滤/报告。据我所知，我有 3 个选择，但没有一个能让我更快乐。

1.) 将参数发送到 Repository/DAO 以获取 DataTable 并将 DataTable 绑定到 UI 控件。例如到 ASP.NET GridView

DataTable dataTable =issueReportRepository.FindBy(specs);
.....
grid.DataSource=dataTable;
grid.DataBind();

在这个选项中，我可以简单地通过域层并查询给定规格的数据库。而且我不必完全构建复杂的域对象。不需要值对象，子对象，.. 直接从数据库中获取数据以显示在 DataTable 中的 UI 中并显示在 UI 中。

但是如果必须在 UI 中显示计算字段，例如方法返回值，我必须在数据库中执行此操作，因为我没有完整的域对象。我必须复制逻辑和 DataTable 问题，比如没有智能感知等......

2.) 向 Repository/DAO 发送参数以获取 DTO 并将 DTO 绑定到 UI 控件。

IList<IssueDTO> issueDTOs =issueReportRepository.FindBy(specs);
....
grid.DataSource=issueDTOs;
grid.DataBind();

在此选项中与上面的相同，但我必须为每个搜索页面创建贫血的 DTO 对象。另外对于不同的问题搜索页面，我必须显示问题对象的不同部分。IssueSearchDTO、CompanyIssueTO、MyIssueDTO....

3.) 将参数发送到 Real Repository 类以获得完全构造的域对象。

IList<Issue> issues =issueRepository.FindBy(specs);
//Bind to grid...

我喜欢领域驱动设计和模式。此选项中没有 DTO 或重复逻辑。但在此选项中，我必须创建许多子对象和值对象，这些对象不会在 UI 中显示。此外，它还需要大量的 ob 连接才能获得完整的域对象和针孩子的性能成本对象和值对象。

我没有使用任何 ORM 工具也许我可以为这个版本手动实现延迟加载，但这似乎有点矫枉过正。

你更喜欢哪一个？还是我做错了？有什么建议或更好的方法吗？

【问题讨论】：

标签： datatable domain-driven-design dto

【解决方案1】：

我有一些建议，但当然总体答案是“视情况而定”。

首先，您应该使用 ORM 工具，或者您应该有充分的理由不这样做。

其次，手动实现延迟加载相对简单，所以如果您不打算使用 ORM 工具，您可以简单地在对象上创建类似以下内容的属性：

private Foo _foo;
public Foo Foo
{  
  get {  
         if(_foo == null)
         {
            _foo = _repository.Get(id);
         }
         return _foo;
       }
}

第三，性能是最初应考虑的因素，但不应使您远离优雅的设计。我认为您应该最初使用 (3) 并且仅在其性能不足时才使用它。这会导致编写最少的代码并在您的设计中具有最少的重复。

如果性能受到影响，您可以在 UI 层使用缓存和/或在您的域层使用延迟加载轻松解决它。如果这两者都无法提供可接受的性能，那么您可以退回到 DTO 方法，在这种方法中，您只传回所需的轻量级值对象集合。

【讨论】：

【解决方案2】：

这是一个很好的问题，我也想提供我的答案。我认为技术上最好的答案是选择选项#3。它提供了最好地描述和组织数据的能力以及可扩展性，以便将来增强报告/搜索请求。

然而虽然这可能是总体上最好的选择，但与其他 (2) 个选项相比，IMO 的成本很高，这些选项是支持报告需求（同样在没有使用 ORM 工具的前提下）。

我在很多应用程序中也遇到了这个问题，而现实情况是，#2 是时间和设计之间的最佳折衷方案。现在，如果您询问您的商务对象及其所有需求，那么没有的问题是，完全布局和适当设计的模型很重要，并且没有替代品。但是，当涉及到向我报告和搜索时，这是另一种动物。 #2 在贫血类中提供强类型数据，不像 #1 这样的 DataSet 中的硬编码值那么原始，并且与 #3 相比仍然大大减少了完成设计所需的时间。

理想情况下，我希望扩展我的对象模型以涵盖所有报告需求，但有时这样做所需的工作量非常大，以至于创建一组单独的类仅用于报告需求是一个更容易但仍然可行的选择。实际上，几年前我问了几乎相同的问题，并且还被告知为报告需求创建另一组类（本质上是 DTO）并不是一个坏选择。

总而言之，#3 在技术上是最佳选择，但在同时考虑时间和质量以满足复杂的报告和搜索需求时，#2 可能是最现实和最可行的选择。

【讨论】：