@makar04

Оправдано ли увеличение и дублирование кода для разбиения логических процессов?

Доброго времени суток!
Пишу приложение для работы с посылками.

Изначально планировалось использовать статусы посылок для отслеживания её состояния и в зависимости от текущего статуса посылки разрешать определённые действия над ней.
Но решил отказаться от данного метода, так как при изменении конфигурации статусов изменяется и логика поведения приложения и может возникнуть путаница и нарушение логики бизнес процесса.

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

Для того что бы найти посылки полученные на складе и готовые к выдаче клиенту надо извлечь из таблицы Посылки, данные о посылках у которых есть номер отгрузки и нет признака продажи и нет номера возврата. Статусы посылок по прежнему есть, но теперь они используются для хранения истории и в случае нарушения конфигурации статусов максимум что может произойти, это записаться в историю неверный статус, а с посылкой произойдёт то, что должно было произойти.

А теперь к самой сути вопроса.
Приняв решение перейти от статусов к процессам, я намерено увеличил код и в некоторых местах даже имеются похожие запросы к БД, кроме того при использовании статусов мне надо было изменять данные только в одной таблице, а теперь в двух, как вы считаете, оправданы ли такие изменения?

По сути к конфигурации статусов никто кроме меня и не должен был лезть, но я побоялся, что спустя какое то время я или кто то залезет в код и может что то изменить в конфигурации статусов таким образом нарушив логику работы приложения. Теперь для того что бы что то нарушить, нужно изрядно потрудится и изменить код конкретного процесса.
  • Вопрос задан
  • 56 просмотров
Пригласить эксперта
Ответы на вопрос 1
@LaRN
Senior Developer
Наверное нужно исходить из того будут ли меняться процессы. Если будут, то ваш вариант сложнее дорабатывать. Если нет, то нужно наметить точки расширения в вашем коде и понять насколько трудно будет вносить изменения так, чтобы не поломать уже работающий код. Как можно будет масштабировать ваше решение, если нагрузка сильно возрастёт. Кроме этого, если требуется по процессу менять синхронно несколько таблиц, значит в целях обеспечения целостности данных нужно такие изменения делать атомарно, т.е. в транзакции.
А добавление транзакции может привести к блокировкам и дедлокам при многопользовательской работе, если конечно количество операций будет большим. В общем чтобы понять плюсы и минусы нужно понять как именно может потребоваться доработать ваше приложение и прикинуть профиль нагрузки.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы