Сколько форматирования столбцов следует использовать в собственном запросе SQL? - PullRequest
2 голосов
/ 11 августа 2010

С тех пор, как я начал использовать 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 #.

Ответы [ 2 ]

5 голосов
/ 11 августа 2010

Это определенно звучит как то, что должно быть сделано далеко от базы данных.Цель базы данных - хранить и предоставлять данные для вашего приложения.Форматирование - это то, что зависит от клиента и не должно быть частью запроса, IMO.

Помимо всего прочего, я подозреваю, что вам будет гораздо проще кодировать / тестировать / отлаживать форматированиев .NET, чем в SQL:)

Теперь это не обязательно означает, что логика должна быть в ваших DTO.Что если у вас есть два разных клиентских представления, которые должны представлять одни и те же данные по-разному?Если ваши DTO действительно предназначены для передачи данных, им не стоит беспокоиться о том, как они представляются пользователю.Это должно быть в вашей логике пользовательского интерфейса.Во что бы то ни стало заставьте DTO преобразовывать представление базы данных (например, «количество секунд») в более идиоматический тип .NET (TimeSpan), но я бы оставил форматирование на уровне пользовательского интерфейса.

1 голос
/ 11 августа 2010

Что ж, на мой взгляд, sql должен предоставлять только минимальное количество форматирования, необходимое для интерпретации данных.

Остальная часть форматирования должна действительно перейти на уровень данных или даже на бизнес-уровень.

...