在原生 SQL 查询中应该使用多少列格式？答案

【问题标题】：How much column formatting should be used in a native SQL query?在原生 SQL 查询中应该使用多少列格式？
【发布时间】：2010-08-11 15:41:30
【问题描述】：

自从我开始使用 ORM 进行日常数据访问以来。我已经开始考虑我应该在多大程度上依赖于我的列的格式化函数。我所说的格式化函数是指 Oracle 的 decode()、instr() 和 initcap()。

示例

假设我正在使用 Oracle 中的格式选择此列。

(to_number(to_char(to_date('1', 'J') + (EndTime - StartTime), 'J') - 1) * 24)
 + (to_char(to_date('00', 'HH24') + (EndTime - EndTime), 'HH24')) 
 || ':' ||
 to_char(to_date('00', 'MI') + (EndTime - StartTime), 'MI')
 as duration_time

这不是很漂亮，我知道。由于使用 ORM（我正在使用 NHibernate）格式化类似的东西可能是浪费时间。我在想我可以简单地让我 DTO 来处理这种格式。我可以在我的 C# set 属性中使用类似的东西。

public TimeSpan DurationTimeSpan
{
 get
 {
  return EndTime.Subtract(StartTime);
 }
}

所以我的问题是，我应该让我的 DTO 对象处理这种格式吗？还是一个 DTO 对象不应该对这种事情负责？就个人而言，让我 DTO 的 set 属性来进行这样的格式化似乎要干净得多。从外观上看，大多数格式可能都可以用非常简单的 C# 来实现。

【问题讨论】：

我的看法是：数据库存储（并检索）数据——原始数据。任何格式或演示都属于 UI（您的应用程序、您的网页、您的报表设计器 - 无论如何）但不在数据库中

标签： c# orm formatting dto

【解决方案1】：

这听起来确实像是应该远离数据库的事情。数据库的目的是为您的应用程序存储和提供数据。格式化是特定于客户的 - 不应该是查询的一部分，IMO。

除此之外，我怀疑您会发现在 .NET 中编码/测试/调试格式比在 SQL 中容易得多：)

现在这并不意味着必须将逻辑放入您的 DTO。如果您有两个不同的客户端视图需要以不同的方式呈现相同的数据怎么办？如果您的 DTO 真的只是为了传输数据，他们不应该担心它是如何呈现给用户的。这应该在您的 UI 逻辑中。无论如何都要让 DTO 从数据库表示（例如“秒数”）转换为更惯用的 .NET 类型（TimeSpan），但我会将格式留给 UI 层。

【讨论】：

我的想法完全正确 - 只是以更简洁和精确的方式表述:-)
感谢您的回答。管理上，我从来没有分离我的 UI 逻辑，但我确实喜欢这个想法。有什么地方可以读到这个话题吗？或者您可以提供一个小样本？
@Mike：我没有例子，但是如果你搜索“n-tier application architecture”你会发现很多信息。

【解决方案2】：

在我看来，sql 应该只提供能够解释数据所需的最少格式。

其余的格式应该真正进入数据层甚至业务层。

【讨论】：