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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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