Sitecore и ASP.net MVC

мы начинаем новый проект с sitecore в качестве нашей CMS. Я думал об использовании Sitecore в качестве инструмента создания контента и использования ASP.net MVC, как и в стороне доставки контента(CDA) вместе с Sitecore. Хотелось бы услышать ваши идеи и мысли по этому поводу.

кто-нибудь пробовал?

является ли sitecore и MVC конкурирующими или дополняющими технологиями?

любые архитектурные идеи приветствуются.

9 ответов


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

для выполнения этой работы необходимо внести пару изменений в HTTP-конвейер Sitecore:

1) при использовании расширения aspx в IIS6 для получения ASP.NET для обработки запросов MVC (например, / Controller.aspx / Action), исправить синтаксический анализ пути к файлу Sitecore (есть ошибка в том, как Sitecore разрешает путь к файлу, который приведет к прерыванию пути).

исправить это, поместите новый процессор в начале конвейера httpRequestBegin.

public class MvcFixHttpProcessor : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor
{
    public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args)
    {
        //when using a path such as /Controller.aspx/Blahblahblah, Sitecore's parsing of FilePath can break if Blahblahblah is too long
        RouteData routeData = RouteTable.Routes.GetRouteData(new HttpContextWrapper(args.Context));
        if (routeData != null)
        {
            args.Url.FilePath = args.Context.Request.Url.LocalPath;
        }
    }
}

(Edit 9/13/2011: мне не приходилось использовать вышеуказанное исправление в течение некоторого времени.)

2) Скажите Sitecore игнорировать URL-адреса, которые маршрутизируются ASP.NET MVC

для этого поместите новый процессор в конвейер httpRequestBegin после ItemResolver.

public class SystemWebRoutingResolver : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor
{
    public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args)
    {
        RouteData routeData = RouteTable.Routes.GetRouteData(new HttpContextWrapper(args.Context));
        if (routeData != null)
        {
            args.AbortPipeline();
        }
    }
}

при использовании языков в URL-адресах Sitecore вам нужно будет добавить некоторую пользовательскую логику, которая объединяет Создание ссылок Sitecore с помощью MVC ActionLink generation, чтобы гарантировать, что язык будет добавлен в начало URL-адреса MVC. Однако с изменениями конвейера выше добавление языка к URL-адресу не должно иметь побочных эффектов на маршрутизацию MVC (потому что Sitecore перезаписывает URL-адрес после чтения языка).

еще раз, этот подход полезен только для определенных типов приложений. В этих случаях Sitecore делает отличный слой данных для вашей модели. Смотреть в создание пользовательских оберток элементов для создания строго типизированных объектов домена на основе элементов Sitecore.

(Edit 9/13/2011: пользовательский генератор элементов отлично подходит для этого. http://blog.velir.com/index.php/2010/10/19/custom-item-generator/)

удачи.


Я думаю, что реальный вопрос, который вы должны задать здесь; Если у вас уже есть Sitecore на месте-зачем вам нужны накладные расходы и усложнение введения MVC?

есть ли у вас какие-либо бизнес-требования за пределами основного веб-сайта, которые потребуют MVC?


Я второй комментарий Марка О требованиях. Стоит ли рисковать? Скорее всего, вы потеряете следующие функции Sitecore, если решите не использовать собственные функции рендеринга:

  1. OMS
  2. веб-формы для маркетологов
  3. Условное Отображение
  4. Редактор Страниц
  5. Конструктор Страница

может быть, даже больше.


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

Я не против ASP.NET MVC с или без Sitecore, но Sitecore, похоже, предоставляет функции контроллера (действительно ASP.NET является контроллером, а Sitecore просто подключается), ваша информационная архитектура-это модель, а компоненты презентации-это представления.


Они конечно могут быть смешаны, и я уверен, что вижу его значение :) Никакая собственная функциональность не теряется с помощью метода, который я описываю в своем блоге здесь: http://www.chrisvandesteeg.nl/2012/02/26/sitecore-mvc/


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

Что касается Sitecore, есть кривая обучения, но, честно говоря, в моем случае, так как я действительно узнал ASP.NET MVC "first" в отличие от веб-форм, кривая обучения также была немного связана с моей неопытностью в веб-формах. Тем не менее, есть еще большинство определенно кривая обучения, связанная с Sitecore, но есть много учебных и справочных материалов, плавающих вокруг, чтобы помочь с этим. Кроме того, веб-элементы управления, которые поставляются с Sitecore, делают его намного менее похожим на создание приложения для веб-форм. Кроме того, есть возможность использовать XSLT в качестве движка рендеринга, который также пригодится.

Если это всего лишь один проект, о котором вы думаете, я бы сказал, просто придерживайтесь Sitecore, поскольку это система презентаций довольно хорошо продуманный. И, как сказал Марк выше, это действительно немного усложнило бы ситуацию, и я также не уверен, что даже выиграю от этого. Также вторя настроениям commodore73, строительные материалы в Sitecore серьезно чувствуют, что вы уже используете MVC, просто используя другую структуру.


MVC в Sitecore имеет потенциал, но не готов к производству, я думаю. Вы покрываете неизвестную землю, как я обнаружил при создании этой статья в блоге.


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

ASP.NET MVC не был для нас проблемой. Это 2015 и мы должны идти вперед с новыми технологиями. Мы используем Sitecore 8, и я думаю, что Sitecore MVC стал зрелым с Sitecore 7.

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


теперь есть проект Хабитат.

Sitecore Habitat-это проект Sitecore, который bulit использует модульную архитектуру. На своем веб-сайте они представляют полностью рабочий пример для установки и тестирования.

ареал:

https://github.com/Sitecore/Habitat