Ниже представлены правила или рекомендации которые необходимо соблюдать при написании нового кода в проекте. Чтобы сохранять единство подхода.

Диалоги

ViewModel и View

Постарайтесь всю логику диалога выносить во ViewModel, View сама по себе должна быть тонкой прослойкой связи между в ViewModel и ГУИ тулкитом. View не должна знать что при определенных условиях надо деактивировать какую-то кнопку, она должна спросить это у ViewModel. Нужно ли подсвечивать строку она должна спросить у ViewModel. То есть View совсем не должна принимать никаких решений о том как сейчас должен работать диалог, она не должна ничего знать о нюансах работы с данными, она должна только уметь их выводить, но не обрабатывать.

Бизнес код

Мы очень стараемся сделать код менее связным и тем самым более гибким и поддающимся более быстрому и простому внесению изменения. Под связностью кода мы в первую очередь понимаем, некое знание одного класса(метода, модуля) о том как устроен другой класс(метод, модуль), а не прямую ссылку или использование одного другим. Этот подход часто называется принципом единой ответственности, и многими другими умными словами.

Складская позиция

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

Складские остатки

Если нужно разово запросить складские остатки можно использовать метод StockBalances из репозитория StockRepository. Но часто со складскими остатками удобно работать многократно запрашивая данные и обновляя их из базы при необходимости, для этого больше подходить StockBalanceModel, которая при однократном заполнении позволяет постоянно обращаться за складской справкой и предоставляет удобные механизмы обновления.

Расчет сроков носки в сотрудниках

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