Блог

Главная - Вопросы по программированию - Кто отвечает за проверку состояния?

Кто отвечает за проверку состояния?

# #go #logic #repository #single-responsibility-principle #chain-of-responsibility

Вопрос:

В настоящее время я создаю систему управления согласием, состоящую из 3 уровней:

  • Обработчики/Контроллеры (Остальные)
  • Услуги (Логика)
  • Репозитории (Microsoft SQL)

Таков сценарий:

Я извлекаю идентификатор (идентификатор) из модели внутри базы данных. Но перед этим я должен проверить, имеет ли логическое значение другой модели значение true или false. У меня была дискуссия с одним из наших инженеров о том, как реализовать его, и, кроме того, кто отвечает за проверку: бизнес-логика или уровень репозитория по SQL-запросам.

Решение 1.Извлеките всю модель/экземпляр из уровня репозитория по двум параметрам, а затем явно проверьте состояние логического значения. (правда/ложь) Используя следующий запрос:

SELECT * FROM [ApplicationUserMapping] WHERE Uuid = @Uuid AND ApplicationUuid=@ApplicationUuid;

Код внутри бизнес — логики:

 if !applicationUserMapping.HasConsent {
    // User is NOT allowed to proceed -> Error messaging -> Logging -> etc.
}

// User is allowed to proceed -> Continue code block

Решение 2:
Или напишите и выполните запрос, который проверяет, соответствует ли состояние логического значения. (правда/ложь) Репозиторий теперь отвечает за проверку состояния. И возвращайте значения в зависимости от результата запроса.

SELECT * FROM [ApplicationUserMapping] WHERE Uuid = @Uuid AND ApplicationUuid=@ApplicationUuid AND HasConsent = 1;

Решение 3: Если вы понимаете мой сценарий и у вас есть лучшее решение, пожалуйста, предоставьте его.

Комментарии:

1. Есть ли у вас данные для applicationUserMapping.HasConsent чтения перед чтением из базы данных?

2. 99,9% времени в «в SQL-только» подход позволит сэкономить циклов обработки запросов между приложением и базой данных и, таким образом, быть гораздо более производительным, с меньшим числом задержек и снижения использования ресурсов на App и DB. Многие разработки команды предпочитают делать схемы базы данных дизайн «через» свои ОРМ или моделей, и в этом случае бенефис необработанного запроса SQL может быть перевешена на трудность согласования нерегламентированные запросы с модели «управляемого» схемам баз данных. Большинство ORM также поддерживают добавление условий в запросы без необходимости выполнять логику сравнения «вне» запроса.

3. Вам все равно нужно сделать запрос. С таким же успехом можно было бы отфильтровать его для вас в базе данных. Бывают ситуации, когда решение № 1 приемлемо, например, когда потребуется создание временных таблиц (сложность отладки 1), чтобы даже выполнить логику в БД. Однако я нахожу, что простые старые SQL-операторы попадают в ORM-клуб смерти чаще, чем это действительно полезно для проекта и тех, кто над ним работает.

4. @advayrajhansa Нет, у вас есть только два доступных параметра (@Uuid и @ApplicationUuid). Эти параметры необходимы для извлечения экземпляра из базы данных. Затем вы можете либо проверить экземпляр на HasConsent. Или мгновенно извлеките базу данных, используя HasConsent = true в SQL-запросе.

5. @DanielFarrell, Но что делать, если запрос не возвращает никаких результатов SqlNoRows. Как мне проверить, не удался ли запрос по одному из двух Uuid (параметров) или потому, что согласие является ложным. Особенно важен для меня последний сценарий. Таким образом, я могу явно сделать некоторые сообщения об ошибках для статуса согласия.

Метки: