Если (друг) EntityFramework оказался вдруг

           выполняющим операции на клиенте, подумайте, где явно и неявно используется IEnumerable<>. Компилятор не скажет вам, где использует LINQ extension methods для IEnumerable<>. И optionsBuilder.ConfigureWarnings(w => w.Throw(RelationalEventId. QueryClientEvaluationWarning)) ничего вам не скажет. Используйте IQueryable<>, и ваши ентити-операции типа Take(), Skip(), Count() лягут на DBMS,а не на backend app.

"И тут я понял", как надо формочки лепить

        Только спустя много лет и проектов появилась идея, как нормальнее делать логику взаимосвязей значений для больших списков Use Cases, для фреймворков, где нет похожего. Долой дергающие друг друга мелкие обработчики OnChange контролов, сбинженых с пропертями business entity. Они, вместе с прочими мелкими методами, поналепленными для code reuse, приводят к непоняткам:

- не прослеживаются связи с конкретными Use Cases из спецификации

- maintainability отстой - давно думаю, что длинный метод и портянка на 1-2 экрана плотного кода, хоть на Domain Specific Language, лучше, чем куча коротких методов, длинные стеки вызовов и необходимость слегка повышенных способностей, чтобы охватить код в достаточном объёме.

        OnChange обработчик может быть 1 для всех контролов, и это вполне может быть единственный метод, содержащий всю калькуляционную или валидирующую логику entity. В цикле с ограниченно разумным числом повторений и бросанием ошибки при превышении, что позволит что-то поменять. Флаг(и) для отключения повторного вхождения через OnChange, равно как и рестарт вычислений как через OnChange, так и через break - этого может быть достаточно для всех случаев. Чем-то напоминает Angular(JS) с его рекалькуляцией пропертей модели?..

            Всё, что относится к бизнес-логике, должно быть плотно собрано в 1 место, и Use Cases должны чётко прослеживаться. Как это будет уживаться с вспомогательными операциями типа загрузки дочерних данных по OnChange какого-нибудь ChildObjectId navigation property, дело другое. Тут уже можно мелкие методы подергать из портянки. А рассовывание той же установки Enabled по разным методам - как сверять с Use Cases будем? Тесты писать?..

            Вышесказанное относится, скорее, к десктопным проектам, к тем же .NET WinForms. И так же относится к каким-нибудь MVP Presenter or any business logic class, куда вы вынесете логику из "View" (UI). Даешь сосредоточение логики в портянке на 1-2 экранах плотного кода. Долой мелкие методы