Дизайн приложения: один или несколько попаданий в БД

Question

Я создаю сервис, который выполняет набор настроенных действий в зависимости от типа запроса, который он получает. Каждое действие включает в себя посещение базы данных и поиск / обновление какой-либо информации. Логика для каждого действия может быть обобщена и повторно использована для разных типов запросов. Действия могут потребоваться для участия в транзакции на время обслуживания запроса.

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

Второй вариант - заключить ВСЕ действия в одно большое действие и один раз попасть в базу данных. Но это не позволяет повторно использовать и настраивать эти действия для разных запросов.

Есть ли у кого-нибудь какие-либо предложения и предложения о том, как лучше всего решить мою проблему? Спасибо за любую помощь.

Answer 1

Боюсь, немного сложно выбрать дизайн без деталей. Мой первый выбор будет следовать за первым вариантом; это звучит как более простой подход. Второй звучит так, как будто он будет работать лучше, но в моей голове есть голос, шепчущий о преждевременной оптимизации и зле.

Это действительно зависит от того, насколько эта услуга будет использоваться. Это будет под большой нагрузкой? Является ли сервер запущенным на мощной машине, на которой запущено всего несколько вещей, или виртуальной машиной вместе с несколькими другими виртуальными машинами, каждая из которых работает с несколькими службами?

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

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

Answer 2

Решение, вероятно, определяется требованиями транзакции.Если все действия должны видеть один и тот же снимок базы данных, они больше не являются независимыми.Таким образом, действия не являются полностью независимыми.

Каково количество запросов к базе данных в обоих сценариях?Т.е. сколько действий будет иметь типичный пользователь power , сколько пользователей в системе и т. Д. Кроме того, при меньшем количестве запросов обычно приходит больше данных - как это выглядит при объединении запросов?

Увеличение количества ударов в минуту с 5 до 10 не является проблемой.увеличение в 5 раз для 1000 пользователей.

Не могли бы вы пакетировать запросы?Вы можете создать интерфейс между активностью и DAL, так что вы можете пакетировать запросы.Например, все действия публикуют свои запросы и получают результаты, а запрос использует набор действий для обработки.Простая реализация request может по-прежнему запускать отдельные запросы.

Answer 3

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

Когда вы сделаете это, вам нужно спроектировать интерфейс - спроектируйте его на основе логических разделов работы: подумайте ISP , SRP , CRP и КПК .

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

Answer 4

Вы можете рассмотреть NServiceBus . Вы можете объединить несколько обработчиков сообщений, чтобы получить желаемый конвейер. Он также запускает все обработчики в одной транзакции, удовлетворяя ваши транзакционные потребности. Поскольку каждый конвейер является автономным, вы можете масштабировать весь день. Единственное предостережение заключается в том, что вам придется выполнять коррелированный запрос / ответ, если вы хотите сохранить эту модель (NSB также поддерживает это).