Дата создания - должно ли это значение быть установлено в BL или DAL?

Question

Дата Созданный конкретный пример, который меня интересует, но есть другие бит данных, которые попадают в ту же категорию: данные, которые вы хотите захватить в отношении любого неопределенно важного объекта.

Где лучше всего это сделать: бизнес-логика (BL) или уровень доступа к данным (DAL)?

До сих пор я полагался на SQL Server getdate() для заполнения даты, созданной для меня при вставке в таблицу, но теперь я начинаю задаваться вопросом, должен ли я делать это больше в BL.

FYI - это в основном было в веб-системах, где вы создаете объект в BL (на основе пользовательского ввода) и запускаете его в DAL - это не похоже на то, что я хотел обратиться к объекту в памяти целых веков (поэтому наличие свойства «дата создания» на объекте для использования в BL при создании объекта не было проблемой).

Возможно, есть третий вариант - это происходит после того, как я прочитал ответ Marr75, что запись его дважды может быть полезна в некоторых сенариях (один раз в обоих местах). Вы получили бы выгоду от согласованной даты/времени в слое данных, но вы все равно должны иметь значение, приведенное в BL, чтобы ссылаться на него, - я думаю, что я буду зависеть от ваших вариантов использования. Однако этот вариант не лишен какого-либо риска, но люди могут начать использовать неправильную дату для неправильной вещи.

Answer 1

Я бы сказал: да.

Возможно, вы привыкли задавать созданные и проработанные даты в своем BL. Затем в вашем DAL всегда проверяйте нули в этих полях. Если они равны нулю, рассмотрите свой вариант: выброс исключения или просто заполнение этих значений на этом уровне. Вид catch-all перед вставкой/обновлением.

У меня была такая же модель, как вы описали в своем вопросе. Затем я столкнулся с тем, что приложение использует/потребляет временные метки UTC, и я решил, что просто переведу это поведение в классы BL и/или DL. Да, я мог бы использовать GETUTCDATE(), но было бы разумнее иметь эту логику в BL/DL.

Answer 2

Я голосую за DAL. Опора на даты и время из слоев за пределами базы данных была источником ошибок для меня в прошлом. В большинстве настроек вы, скорее всего, гарантируете согласованную дату и время из своей базы данных. Проблемы синхронизации времени клиент-сервер и даже сервер-сервер привели к неприятным, трудно дублирующимся, сложным для решения проблем.