Я работаю над приложением, которое использует SQL Server и NHibernate.У нас есть концепция данных по умолчанию (сложные объекты), которые необходимо создавать для каждого нового объекта.Эти данные могут быть изменены для каждого пользователя.Однако мы пытаемся найти лучший способ создания этих данных.
Например, допустим, в моем приложении есть объект Store, который имеет несколько значений по умолчанию Product, которые я хочу создать при создании новогоStore создается.Все, что касается Product, может быть изменено менеджерами каждого Store.
. На мой взгляд, есть два основных варианта:
- Сохранить данные по умолчанию в коде изапишите его в базу данных после создания нового объекта.
- Сохраните данные по умолчанию в базе данных и переместите их с помощью хранимой процедуры / необработанного SQL при создании объекта.
Инстинктивно я склоняюсь ко второму варианту, поскольку базы данных хороши для перемещения и манипулирования наборами данных, а первый вариант потребует тонны грязного кода, который может выйти из-под контроля.
Однако написание хранимой процедурыили необработанный SQL представляет свои собственные проблемы:
- Нам бы пришлось переписать хранимую процедуру или SQL в зависимости от базы данных, которую мы используем
- Мы бы подорвали ORM вспособ (не уверен, если это на самом деле неправильно).То есть мы будем перемещать данные без использования NHibernate
Я нашел эту статью Ayende Rahien, в которой описывается, как выполнять массовое удаление.Я думаю, что сделать что-то подобное для вставки данных по умолчанию было бы хорошо.Я также обнаружил публикацию групп пользователей nhibernate (называемую «Экспорт схемы и данные по умолчанию» - поэтому я не буду публиковать две ссылки), в которой описывается похожая ситуация, но, похоже, нет единого мнения относительно правильного решения.есть (хотя Ayende действительно предлагает некоторую обратную связь и предполагает, что данные живут в базе данных).
После написания этого я склоняюсь еще больше к использованию хранимой процедуры, я просто беспокоюсь о возможных ловушкахсмешивание двух стратегий доступа к базе данных (прямой вызов SProcs и использование ORM).
Любая обратная связь приветствуется!
Редактировать: Удален "неизменный" язык.Я специально говорю о данных по умолчанию, которые могут измениться, поэтому я думаю, что этот термин был неправильным / запутанным здесь.