Где я должен написать бизнес-логику? В интерфейсе (бизнес-уровне) или в хранимой процедуре?

Question

Я пишу приложение ASP.NET с базой данных SQLServer, в которой мне приходится рассчитывать ставки для участников моего приложения.Эти вычисления затрагивают более 10 таблиц базы данных.

Мне кажется, у меня есть два варианта:

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

2. Используйте хранимую процедуру дляинкапсулировать вычисление и сохранение новых тарифов для участника в правильных таблицах в транзакции базы данных.

Какой вариант, по вашему мнению, является лучшим и почему?Если я использую первый вариант, как мне выполнить все вставки и обновления в одной транзакции ADO.NET из уровня бизнес-логики?В настоящее время мне запрещено использовать транзакцию ADO.NET вне уровня доступа к данным.

Answer 1

IMO, это зависит от того, какой приоритет нужно отдать производительности и модульному дизайну.

Если бы это было торговое приложение, в котором мне пришлось бы мгновенно рассчитывать цены по разным таблицам, я бы использовал хранимую процедуру

• Лучшая производительность для определенного объема нагрузки, но когда он получает слишком много запросов, тогда распределенная база данных становится необходимой
• Одним из недостатков является то, что если вы хотите в будущем перейти на другую базу данных (в большинстве случаев это не так), то вам придется перенести сохраненный процесс на новые

Другой вариант, который у меня был бы, - хранить большинство значений в распределенном кэше (например, в memcache) и выполнять вычисления на бизнес-уровне.

• Значения будут предварительно заполнены в кеш, а кеш будет обновляться по мере внесения изменений.
• Это дает гибкость в плане удаления зависимости от базы данных.

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