Должен ли я удалить дочерние объекты с клиента или через сохраненный процесс

Question

Я работаю над обеими частями слоя данных. Я получаю создать procs и слой бизнес-объектов, который будет использовать procs.

Есть ли лучший способ определить, где должно происходить удаление?

Вот сценарий. У меня есть таблица Book с внешним ключом для дочерней таблицы Pages. Если я удаляю книгу, я также хочу удалить страницы. Если удаление страницы не удается, я хочу, чтобы вся книга осталась (транзакция).

Должно ли удаление происходить в управляемом коде (путем создания транзакции, удаления всех дочерних объектов и, наконец, книги) или в процедуре (снова в транзакции)?

Или это имеет значение?

Answer 1

Я бы сказал, что это зависит от того, где вы храните свою "логику" для данных.

1) Если ваши хранимые процедуры в основном "тупые" с простыми вставками / обновлением / удалением. Я бы поместил удаления в объект слоя данных, где у вас был бы более сложный код.

2) ЕСЛИ вы написали много сложных хранимых процедур, где вам нужно проверить бизнес-правила. Сохраняйте логику в SP и сохраняйте уровень данных простым.

На самом деле это то, где вы хотите, чтобы сложность лежала. Не помещайте слишком много правил как в объекты, так и в SP, иначе техническое обслуживание будет слишком сложным.

Answer 2

ну есть 3 пути для этого:

1. сделать это в приложении с TransactionScope
2. сделай это в проце
3. создать каскадное удаление в отношении PK-FK.

в зависимости от того, как выглядит ваш DAL, вам придется сделать выбор. если это ORM, тогда идите с 1. иначе идите с 3.

Answer 3

Если дочерние объекты должны всегда удаляться при удалении основного объекта, лучшее место для этого - база данных. Существуют дельты, которые могут возникать при импорте или запросах, которые не выполняются через графический интерфейс. Подумайте, что произойдет, если вам понадобится удалить все книги издателя, который обанкротился. Никто не будет делать это по одному через графический интерфейс. Поэтому, если в вашей базе данных есть опция каскадного удаления, установите ее. Если не сделать это через триггер.

Прежде чем сделать это, убедитесь, что хотите удалить дочерние объекты. Вы потеряете исторические данные, которые вам нужны? Часто лучше пометить родительскую запись как неактивную, чем удалить ее. Таким образом, вы не потеряете историю заказов книг, потому что вы удалили все дочерние записи, когда книга больше не была доступна. Вы почти никогда не захотите удалить запись, если ваша система включает в себя, систему заказов, складирование или финансовые системы или любую другую систему, в которой дочерние таблицы будут содержать записи, которые имеют историю дат и которые, возможно, потребуется вызывать в отчетах или при исследовании вызовов клиентов. .

Answer 4

Я предпочитаю выполнять дочерние удаления из управляемого кода. Проще убедиться, что все удаления выполняются одинаково, если делать это отсюда, и это дает одно простое место для другого разработчика, чтобы прийти и понять, как работает этот объект.

Answer 5

Назовите меня старомодным, но я всегда позволял бы базе данных делать то, что делает база данных; пусть он позаботится об удалении и вернет значение обратно в вызывающий код, чтобы указать на успех или неудачу операции.

Я знаю, что ADO.NET хорошо справляется с управлением операциями SQL, но обычно я ограничиваю его настройкой соединения, добавлением параметров и запуском хранимой процедуры.