Методы проверки и возвращаемые значения - исключения против состояния модели против Bool

Question

У меня есть правила, требующие проверки данных в моем приложении, которые я обычно проверяю тремя различными способами, и я не уверен, как мне следует проверять и возвращать информацию на контроллер для отображения пользователю.

Iдобавляю объект дома к объекту улицы.Необходимо соблюдать 3 правила.

Правило 1. Номер дома должен быть в диапазоне 0-10

Метод: аннотация / проверка данных с состоянием модели

Обычно я проверяю это правило с помощью простой аннотации данных в модели

[Range(0,10, ErrorMessage = "Blah blah blah")]

И затем выполняю проверку ModelState.IsValid в контроллере.

Правило 2. Комбинация Housenumber и названий улиц должна быть уникальной

Метод: Fluent API / Выдает SqlException

Я бы обычно реализовывал эти правила с помощью FluentAPI следующим образом:

       builder.Entity<Street>(b =>
        {
            b.HasIndex(e => new { e.HouseNumber, e.StreetName }).IsUnique();
        });

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

Правило 3- Улица не может содержать более 10 домов

Метод: проверка сервисного уровня и выдача исключения или возврата false

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

throw new CreateHouseException("Street has reached maximum capacity");

, либо просто возвращает метод false.

Все остальное

Мои модели my views / viewModels настроены так, чтобы при необходимости возвращать сообщение о состоянии с информацией, предоставленной пользователю.

Все это кажется очень несвязанным с проверкой бизнес-правил, которая происходит тремя способами в трех местах.

1. Контроллер проверяет состояние модели
2. Сервисный уровень проверяет правила, закодированные вручную
3. База данных выдает SqlException при нарушении настройки свободного API

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

1. Некоторые говорят, что я не должен передавать модельное состояние на уровень обслуживания, поскольку это плохо для разделения проблем и не помогает сисключение при проверке Fluent API.
2. Создание слишком большого числа исключений для всего, от уровня обслуживания до контроллера, кажется простым решением, но грязное
3. Проверка свободного API выдает исключение, поэтому я долженобработать и объединить Model State и эти исключения каким-либо образом.

Я знаю, что отчасти это может быть личным предпочтением.Но как бы вы объединили эти 3 метода и как бы вы вернули необходимую информацию контроллеру для передачи в представление?