Мысли об оптимизации нескольких приложений .Net

Question

У нас есть ряд приложений ASP.Net, которые были написаны в течение 8 лет. В основном в первые 3-4 года. Они работали довольно хорошо с небольшим обслуживанием, но запрашивается новая функциональность, и мы сталкиваемся с проблемами IDE и платформы. Приложения были написаны на .Net 1.x и 2.x и работают в разных пространствах, но представлены в виде единого набора приложений, которые используют общую панель навигации (реализованную как пользовательский элемент управления). Каждый раз, когда мы хотим добавить что-то в меню в навигации, мы должны изменить это во всех приложениях, что является проблемой. Кроме того, различные версии отчетов Crystal и использование таблиц для организации визуальных элементов приводят к путанице, особенно во всех многоплатформенных версиях .Net. Нам нужно упростить набор приложений и упростить добавление новых приложений без лишних хлопот. Нам также необходимо объединить все эти приложения под одной платформой .Net и IDE.

Кроме того, есть блог WordPress, стилизованный под стиль набора приложений, «интегрированный» в пользовательский интерфейс, а также ссылку на приложение MediaWiki Wiki.

В настоящее время я думаю о том, чтобы использовать систему управления контентом с открытым исходным кодом (CMS), такую ​​как Joomla (к сожалению, на основе PHP, но она хорошо работает), в качестве структуры пользовательского интерфейса для шаблонов стилей и управления меню. Управление статьями Joomla позволило бы нам перенести контент Wiki в статьи, которые можно публиковать, не мешая приложениям .Net. Затем по существу используйте IFrame внутри «статьи» для «размещения» приложения .Net, затем ...

Обновите приложения .Net до VS2010, удалите все общие элементы управления верхнего / нижнего колонтитула и перенесите стили для использования таблиц стилей, используемых в CMS.

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

Я знаю, что мы могли бы использовать стилизацию приложений .Net, но, похоже, гораздо больше работы (не совсем точно). Кроме того, использование CMS для работы с блогом и вики также кажется привлекательным, если только не существует .Net CMS, способной удовлетворить все эти требования.

Учитывая эту информацию, я хочу знать, действительно ли я иду в неправильном направлении? Мы пытались использовать открытый исходный код и интегрировать его с течением времени, но не стало трудно поддерживать. Не знаю ли я о какой-либо технологии, которая будет соответствовать нашим требованиям? Правильно ли мы сделали это и должны ли мы просто сосредоточиться на упрощении .Net? Я понимаю, что независимо от того, что мы делаем, будет много работы. Сообщества значительный опыт был бы полезен. Спасибо !!

PS - полная перезапись невозможна.

Answer 1

Хм, мы находимся в центре проекта по созданию чего-то, что звучит знакомо. Мы используем www.sitecore.net CMS , но вы можете снова использовать альтернативу с открытым исходным кодом Umbraco , и у обоих из них будет кривая обучения, но они являются приложениями и .Net не нацелены специально на блоги. В конечном счете, SiteCore может использовать обычные пользовательские элементы управления .Net, хотя это немного не соответствует их модели, но работает.

Одна вещь, о которой я вас предупрежу, это то, что SiteCore должен быть корнем вашего сайта, он должен контролировать корень домена (у него есть модуль urlrewriting, который должен находиться в корне), и вы можете сказать ему: исключить определенные папки, где могут жить ваши приложения. Очевидно, вы можете поместить свою навигацию в папку под корнем сайта. Также обратите внимание, что SiteCore - это приложение .Net 3.5, работающее в среде выполнения 2.0.

Являются ли ваши суб-приложения .. Фактически отдельные приложения в виртуальных каталогах или что-то, что я предполагаю?

Answer 2

В зависимости от характера приложений .Net может оказаться полезным DotNetNuke .

Это CMS, где вы пишете виджеты («модули») в .Net, а затем добавляете их на страницы CMS. В вашем случае вы бы обернули существующую функциональность в такие виджеты. Я делал это несколько раз, и теперь, когда я к этому привык, это не страшно.

Недостатком является то, что вы должны научиться плавать в среде DNN, которая (как и любая CMS) имеет некоторую кривую обучения.

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

Редактировать : Как и продукт, упомянутый в другом ответе, DNN должен контролировать верхний уровень своего субдомена - все запросы начинаются с прохождения Default.aspx и затем отправляются различными способами. 1015 *