Я работаю над веб-приложением, которое в основном является CRUD-приложением (Create, Read, Update, Delete). Недавно я начал работать над тем, что я называю "процессом утверждения". В принципе, запрос создается для материала, а затем отправляется на утверждение менеджеру. В зависимости от того, что требуется, разные люди должны одобрить запрос или, возможно, отправить его обратно запрашивающему для изменения. Утвердители должны следить за тем, что одобрить утвержденное, и запрашивающие лица должны видеть статус своих запросов.
Как разработчик "CRUD", у меня с трудом завертывается, как это сделать. Какие таблицы таблиц должны быть у меня? Как отслеживать состояние запроса? Как я должен уведомлять пользователей о действиях, которые произошли с их запросами?
Является ли их шаблон дизайна, который может помочь мне в этом? Должен ли я рисовать государственные машины в моем коде?
Я думаю, что это общий вопрос программирования, но если это имеет значение, я использую Django с MySQL.
Утверждение == Изменение состояния
Изменение состояния == Обновление для того, что изменилось && & Создание журнала для записи того, что что-то изменилось.
Что это.
Интересными правилами являются "кто разрешил делать обновление?", "Какие изменения состояния являются юридическими обновлениями?" и "какие состояния являются тупиками"?
Вы строите конечный автомат. Состояние является атрибутом объекта. Вы нажимаете что-то "через рабочий процесс", обновляя его состояние.
Для этого существуют шаблоны проектирования. Может быть, они помогут немного:
http://en.wikipedia.org/wiki/Workflow_patterns
Рабочие процессы более ориентированы на состояние, чем простые CRUD-приложения, поэтому да, чтение на шаблонах государственных машин также поможет. Похоже, вы на правильном пути.
Что касается моделирования данных, у вас может быть таблица всех "утверждений" с полем состояния, которое является внешним ключом для таблицы состояний.
Что касается уведомлений, то что-то, что ваше приложение должно будет делать, когда оно изменит состояние одобрения, ему придется искать где-то в другом месте, чтобы узнать, кто/что нужно уведомлять для определенного изменения состояния (так что вы будете иметь для отслеживания того, какие сущности получают уведомление, для каких изменений состояния).
Как многие говорили, утверждая, что он переводит его в новое состояние.
Что-то, с чем я столкнулся, - это то, что я часто обнаружил, что пользователи хотят иметь вещи в одном и том же состоянии, но также записывают, что все вещи находятся в другом шаге или задаче в этом состоянии. Например, пользователи могут различать "запрошенные" и "in process". С точки зрения одобрения, запрошенные и находящиеся в процессе работы, оба являются неутвержденными (открытыми). Если что-то идет от одобренного до неутвержденного (открытого), они могут назвать это "требуемым обзором", но он все еще не одобрен.
Итак, вам может понадобиться что-то вроде этого:
Запрошено: Открыть
В процессе: Открыть
Требуется обзор: Открыть
Утверждено: одобрено
Со временем ваши пользователи, возможно, захотят больше "режимов" или "задач". Если вы создаете состояние для каждого из них, вы можете оказаться намного сложнее, чем вы, или они действительно хотели. Если вы позволяете пользователям иметь столько "режимов" или "задач", сколько им нужно, с отношением "много к одному" с состояниями, это будет проще с вашей точки зрения, но более точно с точки зрения пользователя.
Это так часто возникало для нас, что мы создали общую систему маршрутизации. Вероятно, это слишком сложно для того, что вы делаете, но вы можете поделиться своими идеями. Он позволяет произвольно использовать произвольный контент произвольным пользователям, используя либо цепочку (последовательное утверждение), либо звезду (трансляцию) с минимальными голосами для утверждения. Здесь - автогенерация ERD схемы.
В принципе у нас есть схема маршрутизации, которая содержит один или несколько списков схем маршрутизации. Каждый список может быть либо цепью, либо звездой, и вся схема может быть инициирована как цепочка или звезда. Каждый список и целая схема могут иметь свои собственные голоса_to_approve. Это означает, что у вас может быть схема с типом "звезда" с двумя списками, одной звездой и одной цепью. Вся схема может иметь vote_to_approve of 1, поэтому, если любой из них одобряется, весь рабочий процесс одобрен. Список цепочек может иметь vote_to_approve, равный количеству членов, чтобы каждый член должен был одобрить до того, как следующий участник сможет проголосовать, а первое, кто отклонил, уничтожит этот список. В списке звезд вы можете иметь vote_to_approve 1, чтобы каждый из этого списка мог мгновенно утвердить весь рабочий процесс.
Эти схемы сохраняются неограниченно и могут быть повторно использованы после установки. Чтобы реализовать схему, запись в таблице маршрутизации производится с помощью schem_id, вещью для маршрутизации и некоторыми деталями, такими как текст утверждения и отклонения. Затем таблицы "routing_" сохраняют состояние реализованной схемы.
Мы используем систему событий с несколькими приложениями для отправки электронных писем или информирования других приложений, когда состояние маршрута изменяется.
Я сейчас в аналогичном проекте (другая платформа/БД).
У меня есть приложение DB с различными уровнями прав пользователя, какие типы записей они могут CRUD. В большинстве случаев я контролирую допустимые операции в коде.
Однако для ряда конструкций у меня есть "код состояния" для конструкции, который затем определяет (опять же, в коде), кто может делать то, что для этой конструкции, и какие коды состояния они могут переместить.