Веб-приложения - объединять или разделять?
Для нашей компании я создаю большой веб-сайт Extranet, который будет содержать набор суб-приложений. Я немного озадачен тем, какой должна быть правильная настройка решения и проектов.
У меня есть одно веб-приложение, которое мы называем Портал. Он содержит классы аутентификации / авторизации, мастер-страницы, классы навигации / маршрутизации URL и определения тем. Он также будет содержать некоторые основные обзоры для наших клиентов, чтобы быстро понять их статус проекта.
В следующем году мы собираемся разработать и интегрировать больше приложений с порталом. Думайте об этом как о подробных обзорах и инструментах под названием Функции A, B и C. С годами мы будем совершенствовать эти приложения и выпускать новые версии. Эти веб-приложения должны легко вписываться в навигацию портала. Я хотел бы, чтобы они повторно использовали шедевры и темы.
Как правильно настроить это решение?
Как я могу связать приложения вместе, повторно использовать главные страницы и поддерживать их в рабочем состоянии?
Как правильно поделиться определенными веб-элементами управления (ASCX)?
Мы используем TFS, может быть, есть какие-либо идеи ветвления / слияния?
Редактировать:
Я хотел бы создать его в ASP.Net WebForms, у нас больше всего опыта в этой области. Но в основном мы можем использовать все что угодно, у нас есть веб-сервер под нашим собственным контролем (если он ориентирован на Microsoft, не переключаясь на php или что-то в этом роде:))
7 ответов
What is the proper way to setup this solution?
Правильный путь... Их так много. Я видел множество приложений и множество различных настроек (многие из которых я бы назвал "правильными"). То, что вы действительно спрашиваете, это лучший способ для вашей ситуации.
Поскольку вы создаете портал, у вас будет возможность разделения функций, которая поможет вам при разработке дополнительных функций для вашего приложения.
Я бы настроил один сайт с отдельной папкой для каждой функции. Создание единого веб-сайта позволит всем функциям совместно использовать одни и те же мастер-страницы, пользовательские элементы управления и файл конфигурации - без необходимости делать что-то особенное. (В этой заметке я бы поместил все ваши главные страницы в одну папку и создал другую папку для ваших пользовательских контролей).
How can I tie the applications together, re-use the master pages and keep it maintainable?
Опять же... папки являются лучшим вариантом здесь. Папки помогут отделить каждую функцию, упрощая управление приложением.
How can I share certain webcontrols (ASCX) in a proper way?
Прежде всего, файлы ascx не являются веб-элементами управления. Это пользовательский контроль. WebControl - это класс для создания серверных элементов управления, которые находятся в отдельной сборке. Что касается пользовательских контролей, как я уже сказал выше, если вы поместите их в отдельную папку, они всегда будут в одном месте и доступны во всем приложении.
We are using TFS, perhaps any branching/merging ideas?
Здесь действительно нет ничего особенного, что вам нужно делать. Есть много разных путей, которые вы можете выбрать в отношении ветвления:
- Одним из них является создание ветки для каждого выпуска.
- Другой - создать ветку для каждой новой добавляемой вами функции (в вашем случае это почти то же самое, что и первая опция).
- Еще одно - создать ветку для каждого разработчика.
Когда я решаю, как я собираюсь ветвить свой код, я думаю о том, что защитит меня больше всего. В вашем случае вам нужно планировать исправления ошибок между выпусками функций, так что, возможно, одна ветвь после каждого выпуска наиболее целесообразна (назовите это вашей веткой разработчика). Однако, учитывая разделение функций, одна функция может не повлиять на остальную часть приложения. Вам может не понадобиться такой вид ветвления, чтобы быть в безопасности.
Как говорит Брайан, когда публикуете API, вы должны как можно больше фиксировать его, а это значит, что он должен меняться как можно меньше после первоначального выпуска. Однако, чтобы сделать что-то стабильное, нужно приложить немало усилий, поэтому, если вы не готовы использовать API, вам следует как можно больше его усвоить, и по этой причине вы можете захотеть объединить вещи, а не разделять их.
Однако я не собираюсь предлагать архитектуру, которая подходит вашему приложению на основе описания из 5 параграфов. Что вам нужно сделать, так это взвесить плюсы и минусы нескольких крупных проектов, а не кучку слабо связанных небольших проектов. Я имею в виду, что чем больше вы планируете заранее, тем легче вам будет это делать, если вы будете придерживаться плана.
Поэтому, вопреки ответу Брайана, я бы не советовал вам делать всю систему "настолько слабой, насколько это возможно", только чтобы вы делали ее настолько слабой, насколько это необходимо.;) Слабосвязанный код может вызвать столько же проблем, сколько и тесно связанный, если вы злоупотребляете им.
Увидеть:
1. Что лучше, много маленьких сборок или одна большая сборка?
2. Конкретные недостатки многих-малых собраний?
В конце концов, только вы знаете, насколько вы хотите сосредоточиться на каждой из "... способностей", удобстве обслуживания, расширяемости, надежности и т. Д. Так что определите свои приоритеты и цели и планируйте соответственно.
Что касается стратегий ветвления, вы можете прочитать Руководство по ветвлению TFS 2.0, в котором есть хорошее представление о различных стратегиях ветвления - от базовых до продвинутых. Даже если вы не используете TFS, это хорошее руководство для чтения (сейчас я использую SVN). Поскольку в настоящее время я работаю в небольших командах с 1-4 разработчиками, я склонен использовать стратегию, которая находится между базовой и стандартной. Не то, чтобы я рекомендовал это для вас, но это лучше всего подходит для нашей команды.
Что касается обмена кодом между проектами. В SVN мы можем использовать " внешние", что означает, что общий файл появится в нескольких папках, поэтому, когда вы меняете одну копию и фиксируете изменение в svn, все остальные копии будут обновлены при следующем обновлении svn. Тем не менее, я не могу вспомнить, есть ли в TFS нечто подобное.
Примечание: остерегайтесь внешних факторов в SVN... они могут вызвать... проблемы.;)
Мой совет - стараться как можно больше не делиться aspx, ascx и master страницами. Обычно болит гораздо больше, чем помогает. Вместо этого попробуйте использовать наследование или другие альтернативы для достижения вашей цели.
ASP.NET MVC 2.0 имеет концепцию под названием "Области", где вы строите подразделы приложения изолированно от остальных. Насколько я знаю, эти участки можно поддерживать в отдельных проектах от "основного" приложения. Это звучит очень похоже на то, что вы запрашиваете, так что, возможно, вам следует рассмотреть это.
Надеюсь, это имеет смысл.;)
Возможно, вам будет полезно взглянуть на реализацию пользовательского VirtualPathProvider. В моем последнем проекте у нас было несколько сайтов ASP.NET, которые должны были обмениваться файлами тем (главные страницы, пользовательские элементы управления, изображения, таблицы стилей), поэтому я создал VirtualPathProvider, который позволил нам сопоставить виртуальную папку (например, /Themes) с любой физической папка на жестком диске (например, C:\Shared\SiteThemes).
Это не тривиально, но не займет много времени и не вызовет никаких проблем. Между прочим, это был отличный способ преодолеть максимальный лимит компонентов в WiX... Обратите внимание, что вы не можете прекомпилировать сайты, которые используют VirtualPathProvider.
Я бы посмотрел на то, чтобы сделать вашу систему максимально слабосвязанной. По мере того, как вы добавляете больше приложений, ваш веб-сайт становится все менее и менее надежным (поскольку ни один из компонентов не будет работать 100% времени, их объединение снизит общую надежность). Поэтому вы должны построить свою систему для обслуживания неосновных сервисов (я считаю, например, что на домашней странице Amazon есть 100 сервисов, способствующих этому, и поэтому она создана для отказоустойчивости).
Ваши API-интерфейсы между службами должны оставаться настолько стабильными, насколько это возможно, чтобы реализации могли меняться, не нарушая связи. Вам также следует изучить автоматическое тестирование этого на веб-уровне (возможно, Selenium или аналогичное?), Поскольку тестирование отдельных сервисов мало что даст вам в отношении общего поведения.
Используйте MVC Concepts с этого момента. они дают больше расширяемости и гибкости для надежных приложений.
Я бы не думал о приложениях как об отдельных, но как о модулях всего портала.
Я бы порекомендовал вам взглянуть на MEF, так как это может показаться вам идеальным вариантом.
http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx
Вы можете посмотреть на использование SharePoint. Это довольно приличная платформа для доставки приложений ASP.NET, особенно если они сосуществуют в среде интрасети; это дает вам много вещей бесплатно.
Конечно, у него очень грубые локти, так сказать, поэтому будьте осторожны.