Question

自从我开始使用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＃来实现。

Answer 1

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

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

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

Answer 2

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

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

应该在本机SQL查询中使用多少列格式？

2 个答案: