ERP: Существует ли шаблон проектирования для обновления данных для отдела при сохранении старых данных для второго отдела в течение определенного времени?

Не так сложно, как следует из названия. Представьте себе два отдела в компании: продажи и производство. В то время как данные (в программном обеспечении ERP) в разделе «Продажи» могут представлять собой контракты, «Производство» должно иметь дело с производством, установленным этими контрактами (например, производство 1000 ручек в месяц). Проблема здесь заключается в том, что отдел продаж должен иметь возможность обновить контракт в любое рабочее время, но не должен прерывать производство до конца дня. Другими словами, для производителя данные контракта должны отображаться как старые до обновления. Для Продаж контракт должен отображаться как новый обновленный. Производство должно «увидеть» обновление только на следующий день.

Это приложение Java ERP. Как справиться с такой ситуацией, используя передовую практику или шаблон проектирования?


java erp business-logic datapersistance
person PDuarte    schedule 14.07.2014    source источник
comment
Поместите изменения в очередь, а затем в конце дня переместите очередь в производство.   -  person TheBetaProgrammer    schedule 14.07.2014
comment
Ваш вывод о том, что отдел продаж имеет тенденцию путаться с производством, кажется... слишком точным.   -  person ajb    schedule 14.07.2014
comment
Спасибо за предложение TheBetaProgrammer. Я думаю, что ваша идея работает, но я также вижу некоторые ограничения и риски. Используя очередь, я не могу так легко извлекать данные из обновлений, например, если отделу продаж необходимо ознакомиться со своими изменениями. Риск возникает, когда очередь сбрасывается в базу данных. Эта операция может привести ко многим проблемам несогласованности данных.   -  person PDuarte    schedule 15.07.2014

Ответы (1)


arrow_upward
0
arrow_downward

Для меня это звучит как шаблон модель-представление-контроллер. Я думаю, было бы лучше, если бы вы создали класс для хранения фактических данных, и он передал бы эти данные классам Sales и Manufacture.

Что бы вы сделали тогда, так это всякий раз, когда класс Sales хочет обновить контракт, он внутренне помечается рабочим временем, когда он был опубликован. Затем всякий раз, когда класс Manufacture хочет получить информацию о контракте, все, что было опубликовано в течение этого рабочего дня, игнорируется и не возвращается.

Как вы хотите это сделать, во многом зависит от вас. Идея TheBetaProgrammer прекрасно работает, но усложняется тем, что вы хотите иметь разную видимость для разных отделов. Возможно, вы захотите создать класс, в котором хранятся разрешения контракта и видимости, а когда запрашиваются данные, проверьте, разрешено ли запрашивающей стороне просматривать эту версию контракта, прежде чем возвращать ее.

person Jonathan    schedule 14.07.2014
comment
Это отличное предложение. Я думаю, что работа с датами публикации и датами истечения срока действия — это путь. Код остается ясным, и мне не приходится иметь дело с пост-обновлениями, которые легко могут привести к несогласованности данных. Спасибо, Джонатан. - person PDuarte; 15.07.2014