Правильный способ разработки большого приложения

Question

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

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

Я развертываю главное приложение в пуле IIS-Master, приложение поставщика A в пуле IIS-A и приложение B поставщика в пуле IIS-B. Пул IIS для балансировки нагрузки при большом количестве пользователей.

Также это веб-приложение основано на доступе, то есть пользователю необходимо войти в систему для доступа к страницам. Я понимаю, что и здесь нужно реализовать единую регистрацию, поскольку задействованы разные сайты.

Это хорошая идея? Есть ли альтернатива?

---

РЕДАКТИРОВАТЬ ПОСЛЕ ОТВЕТОВ

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

Answer 1

Мое первое впечатление от того, что вы написали, это то, что, возможно, стоит пересмотреть архитектуру.

В случае фреймов вы столкнетесь с множеством проблем, во-первых, поведение кнопки возврата браузера.

Возможной альтернативой может быть использование удаленного взаимодействия или веб-служб между главным приложением и A и B и обработка всего пользовательского интерфейса в одном месте. Может быть очень сложно согласовать разработку согласованного пользовательского интерфейса с двумя разными поставщиками.

Answer 2

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

Answer 3

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

Я лично считаю, что основы программного обеспечения, такие как контроль версий, непрерывная интеграция, обзоры кода и открытая коммуникация, очень хорошо масштабируются. Я предлагаю думать об этом проекте как ОДНОМ приложении, которое написано несколькими командами разработчиков. Возложите на кого-то ответственность за интеграцию кода, убедитесь, что все команды находятся на одной странице, и не меняйте свою архитектуру в соответствии с динамикой вашей команды.

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