Объединение проекта sitecore с другим проектом .net

Question

У меня есть уникальное требование, которому я должен соответствовать с sitecore, и мне было интересно, выполнимо ли это. У клиента есть существующее решение .net, которое представляет собой веб-проект (веб-сайт, а не веб-приложение), построенный на платформе Spring и коммерческом сервере. Теперь они хотят использовать sitecore для включения редактирования контента на «некоторых» своих страницах. Требование состоит в том, что они не хотят поддерживать главные страницы и любые общие элементы в sitecore, но они хотят, чтобы sitecore мог использовать главные страницы и все элементы управления, которые они имеют в своем собственном решении. Я проверил их проект, и у них МНОГО зависимостей от многих других ссылок и проектов, так что это не совсем простое приложение. Они не хотят, чтобы главные страницы были специально для sitecore, и им нужен только sitecore для редактирования основного контента. Они в основном хотят, чтобы все макеты в sitecore использовали свои главные страницы. Я пытался использовать виртуальные каталоги, а затем использовать мастер-страницы в sitecore, но в их проекте слишком много зависимостей. Я пытался сделать sitecore приложением в своем собственном каталоге, но, похоже, оно работает не очень хорошо. Я могу объединить web.configs столько, сколько смогу, но это приведет к головным болям в будущем, когда придет время обновляться ... Мой более высокий вопрос - это вообще выполнимо, и если есть способ Я могу удовлетворить это требование.

Answer 1

Я думаю, что вижу несколько вариантов, как это сделать.В настоящее время я делаю нечто подобное прямо сейчас для крупного корпоративного проекта, где есть существующее приложение ASP.NET MVC, которое выполняет основную часть сайта.Вот некоторые варианты, которые я могу придумать:

1. Использовать субдомен для содержимого только для Sitecore и <iframe> в содержимом Sitecore или выполнить HTTP-GET для страниц Sitecore ивытащить контент в существующее приложение.Например, sc.mysite.com - это приложение Sitecore.В настоящее время я делаю это с MVC сейчас, и это нормально.Из POV управления контентом редакторы могут по-прежнему использовать режим редактирования страницы на страницах Sitecore в их автономном состоянии, но контент находится в рабочем состоянии в состоянии подачи на главном сайте MVC.

2. Sitecore может использовать MasterPages, он просто побеждает назначение уровня представления Sitecore.По сути, ваш макет Sitecore может наследоваться от MasterPage, и он работает так же, как любое обычное приложение с наследованием.Я не уверен в последствиях кеширования, хотя.Пока ваше приложение ссылается на сборки Sitecore, вы можете использовать API, если оно является частью контекста Sitecore.Если вы действительно используете MasterPages с Sitecore, убедитесь, что вы добавили заполнитель с ключом webedit , чтобы разрешить работу редактора страниц: <sc:placeholder key="webedit" runat="server" />

Answer 2

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

Три идеи приходят на ум.

1) Рассмотрите возможность разделения решений и размещения определенных страниц Sitecore в чистом, стандартном,Sitecore решение.Используйте балансировщик нагрузки, чтобы указать, какие URL-адреса указывают куда.У этого подхода может быть много побочных эффектов, связанных с сеансами и т. Д.

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

3) Используйте Sitecore в качестве хранилища контента, но обслуживайте контент из существующего решения веб-сайта.Это будет иметь множество усложняющих факторов из-за отсутствия типичного элемента Sitecore, контекста сайта и домена, который должен был бы обрабатываться пользовательским кодом.Решения могут быть совершенно отдельными и даже использовать веб-службы для извлечения контента из Sitecore, который обслуживается существующим решением.Это дает полное разделение, но вы теряете большую часть функциональности Sitecore и в итоге получаете дорогой многофункциональный текстовый редактор + базу данных.

Я бы выбрал # 2, где это возможно.