Многоквартирные дома AngularJS

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

Добавив все это, мы поняли, что архитектура с несколькими арендаторами, вероятно, будет лучшим подходом, чтобы это произошло. Бэкэнд намного дальше, чем дизайн, и RESTful api in.net строится с ServiceStack, RavenDB и Sql Server. Любой, кто знаком с ServiceStack, будет знать, что он чрезвычайно гибкий и построенный с учетом вместимости - это сделало внедрение многопользовательского REST api намного проще, чем мы ожидали. Мы используем очень простое соглашение для идентификации и авторизации арендаторов, проверяя значение в сеансе, принадлежащем каждому запросу (все запросы, связанные с арендатором, должны быть аутентифицированы, чтобы всегда существовать сеанс). Таким образом, в настоящее время практически нет необходимости отслеживать или передавать идентификатор арендатора от клиента в любом URL-адресе маршрута. Итак, для бэкэнд-апи мы достигли нашей цели разработки единой базы кода, поддерживающей разных клиентов, с хорошим количеством повторного использования кода и гибкостью для индивидуальной настройки/расширения функциональности арендатора по мере необходимости.

Таким образом, с бэкэндом, в основном в квадрате, мы обратили наше внимание на интерфейс, где мы действительно пытаемся реализовать подобный подход с несколькими арендаторами в AngularJS. Отчасти проблема заключается в том, что мы относительно новичок в angular. У нас есть опыт создания одноцелевых приложений с использованием стандартного "шаблона папок", но когда мы смотрим на наши требования многопользователей, мы действительно пытаемся связать все вместе (общая структура проекта/маршруты/представления) для поддержки одного и того же мульти -назначенные цели дизайна в AngularJS, которые мы достигли с помощью бэкэнд (единая база кода, поддерживающая повторное использование, гибкость и настройку). шаблон модуля кажется отличной возможностью "подключать" пользовательскую функциональность для каждого арендатора, но большая вещь, которую мы все еще не видим, - это общий подход к архитектуре что дает нам единую кодовую базу AngularJS, поддерживающую упомянутые выше цели. Могут ли любые профили AngularJS помочь нам преодолеть горб и рекомендовать здесь подход?

Спасибо!

Ответы

Ответ 1

Это вопрос дизайна, поэтому мой ответ будет высоким.

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

Положите, какие изменения в каждой из перечисленных ниже переменных (насколько это возможно).

Подход a). Если вы считаете, что изменения в переменных для арендатора manageable создают 1 приложение, которое обрабатывает всех арендаторов. Что такое manageable? Вы можете выполнить одно упражнение, выполнив Обработка изменений в переменных ниже. Посмотрите, можете ли вы управлять вещами на metadata. Это понимается путем понимания различий между арендаторами для каждой переменной.

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

Подход a) Обработка вариаций в переменных

1) Look and Feel - Skin Используйте один CSS для каждого арендатора.

2) Данные Если схема JSON отличается, у вас есть проблема. Я бы предложил просто перейти к подходу b). Если вы видите добавленные поля + вычитаемые, вы в порядке. Очень рекомендую создать схему JSON.

3) Формы ввода Я рекомендую управлять Формами из схемы JSON + некоторые метаданные. Сможете ли вы использовать тот же самый храм AngularJS со множеством ng-if, ng-switch для вариантов арендатора? Если нет, то перейдите к отдельной ФОРМЕ. Вы попадаете в слишком много таких "отдельных ФОРМ"? Затем вы вернетесь к подходу b).

4) Проверка формы

Вы можете использовать схему JSON и украсить ее атрибутами проверки. (Не знаю, что предлагает ваш стек, но в Java Bean аннотации проверки довольно удобны - вы можете их экстернализировать во время сборки и связывать их с клиентом, чтобы поля ввода форм могли иметь правильное применение валидации из схемы.)

5) Рабочий процесс Если вы видите, что логика маршрутизации изменяется на каждого клиента - используйте маршрутизаторы angular и укажите маршруты для каждого арендатора.

6) Отчетность Предполагая, что это некоторые взгляды, которые учитываются для каждого арендатора. Насколько они отличаются? Если вы можете использовать ng-if/ng-switch, не загромождая шаблоны, вы можете пойти иначе, создайте отдельные шаблоны, представления (маршруты могут заботиться о представлениях).

7) i18n/l10n У AngularJS есть куча утилит, таких как $locale, ngPluralize, различные фильтры, такие как валюта, данные, число. Оформить заказ AngularJS i18n

В целом хороший дизайн metadata, Validation decorated JSON schema и good routing ([AngularJS routing ][2]) design поможет вам сохранить одно приложение с несколькими арендаторами, которым вы можете управлять в течение всего срока службы продукта.