Решение ASP.NET MVC для приложения форм?

Question

Мы создаем систему опроса и используем ASP.NET MVC и задаемся вопросом, может ли кто-нибудь предложить предложения по архитектуре.

Вот проблема, которую мы пытаемся решить. По сути, агентство ежегодно рассылает несколько опросов. Они очень структурированы и не похожи на опросы SurveyMonkey - они фактически являются приложениями обратной связи. Как и в случае с визовым заявлением, есть много вещей, которые им нужно делать, и иногда для их заполнения требуется 2-3 недели.

Они могут загружать файлы (доказательства покупки и т. Д. - PDF/JPG), а также несколько «предметов». Например. Скажем, например, они работали в McDonalds, может быть 20 разных франшиз, они строят список мест, в которых они работали. Через 3 недели могут быть еще 3 новых места, а 2 могут быть закрыты. Поэтому мы должны обеспечить, чтобы формы могли обрабатывать эти ситуации.

Изменения самих форм (разметки и данных) меняются каждый год - я должен упомянуть об этом для системы налогообложения/финансов/бюджета.

Мы думали использовать MVC, используя Xml для хранения данных (временно), XSD для проверки данных, XSL для преобразования данных в презентабельную разметку (для их заполнения), а затем после их отправки приложение хранится в БД в соответствующих областях.

Когда пользователь запускает процесс приложения, он может сохранить прогресс до сих пор (мы проверяем все, что они навязываем, и игнорируем любые их havent), сохраняйте его как блочную копию Xml и храните в БД. Когда они, наконец, готовы его отправить, мы проверим полную проверку и загрузим файлы и надежно сохраним их (у вас есть свои бизнес-доказательства и бухгалтерские отчеты), а затем запустите некоторые рабочие процессы.

Что меня действительно волнует, так это то, как управлять изменяющимися версиями форм (год спустя). Как написаны системы форм/приложений в наши дни? У нас есть 2 месяца, чтобы снять это и около 30 форм для доставки. Итак, 30xXML, 30xXSD, 30xXSL.

Answer 1

Этот может быть примером для интеграции с Windows Workflow Foundation, поскольку вы говорите о сохранении состояния продолжительного рабочего процесса (завершение приложения).

Если вы можете разделить различные компоненты процесса приложения, вы можете изменить рабочий процесс в будущем, удалив, перенаправляя и/или изменяя существующие части рабочего процесса.

Это говорит о том, что у вас могут быть довольно трудные временные ограничения. Возможно, стоит потратить несколько часов на исследование WF, но внимательно изучите, может ли введение чего-то нового поставить под угрозу ваш крайний срок.

Что касается XML, XSD, маршрута XSL, я думаю, что это зависит от опыта вашей команды. Лично я уклоняюсь от этого и сохраняю данные в одной или нескольких таблицах «ожидающих приложений» в реляционной базе данных. Оттуда (конечно, вы можете сделать это и из XML), создать правильные бизнес-объекты и модели, к которым могут привязываться мои MVC-представления. Проверка на уровне поля выполняется с помощью проверки или проверки работоспособности предприятия и т. П., А окончательная проверка выполняется одним или несколькими классами валидатора, которые проверяют все составные части приложения.

Чтобы устранить возможные изменения, держите чистое разделение между каждой из 30 форм. В следующем году вы сможете изменить данную форму, не испортив других. Помните, вы всегда можете подклассифицировать или составить тип модели, если в будущем будут появляться новые требования, а у вас нет , чтобы удалить устаревшие части - ваши новые взгляды просто не будут раскрывать определенные части модели.