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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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