Frage

Wir beginnen ein neues Projekt mit Sitecore als unser CMS ab. Ich dachte, die Verwendung von Sitecore als Content Authoring Tool und verwenden Sie ASP.net MVC wie in der Content delivery (CDA) Side zusammen mit Sitecores. Würde gerne Ihre Ideen und Gedanken auf das hören.

Haben jemand versucht das?

Sind Sitecores und MVC konkurrierende oder ergänzende Technologien?

Jede architektonische Ideen sind willkommen.

War es hilfreich?

Lösung

Für bestimmte Fälle kann es sein großer Vorteil für die beiden fusionierenden. MVC ist nicht so groß von einem Sitz für Content-orientierte Websites. Jedoch, Web-Anwendungen mit strukturiertem Fluss und mehreren Präsentationen von Daten profitieren enorm davon. Sitecores hat etwas von einer Einschränkung, wenn es um mehrere Präsentationen von Daten kommt - man kann nur eine Reihe von Design-Details zu einem Elemente definieren. Wenn Sie Anforderungen nicht für WYSIWYG-Bearbeitung oder einfache Ein-Klick-Vorschau, können Sie Sitecore als Daten-Repository verwenden, und nutzen Sie einige der Context-Werte, die von der Pipeline (zB Sprache) kommen.

Ein paar Änderungen sind notwendig, um die Sitecores HTTP-Pipeline diese Arbeit zu machen:

1) die aspx Erweiterung in IIS6 Bei der Verwendung von ASP.NET MVC zu bekommen Anfragen (zB /Controller.aspx/Action), fix Sitecores FilePath Parsen (es ist ein Fehler, wie Sitecores löst den FilePath zu behandeln, die in führen der Weg gehackt zu werden).

Um dies zu beheben, legen Sie einen neuen Prozessor zu Beginn der httpRequestBegin Pipeline.

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 2011.09.13:. Ich habe nicht die oben fix in einiger Zeit verwenden musste)

2) Sagen Sie Sitecores URLs zu ignorieren, die zu ASP.NET MVC geroutet werden

Um dies zu erreichen, legen Sie einen neuen Prozessor in der httpRequestBegin Pipeline nach dem 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();
        }
    }
}

Wenn Sprachen in Ihrer Sitecores URLs verwenden, müssen Sie einige benutzerdefinierte Logik hinzufügen, die mit MVC Action Generation Sitecore Link Generation kombiniert, dass die Sprache, um sicherzustellen, zu Beginn Ihrer MVC URL hinzugefügt wird. Jedoch mit den Pipeline-Modifikationen, die oben sollte die Zugabe von Sprache auf die URL hat keine Nebenwirkungen auf MVC Routing (weil Sitecore die URL nach dem Lesen der Sprache neu geschrieben).

Wieder einmal ist dieser Ansatz nur nützlich für bestimmte Arten von Anwendungen. In diesen Fällen jedoch macht Sitecores eine ausgezeichnete Datenschicht für Ihr Modell. Schauen Sie in benutzerdefinierten Element Wrapper Erstellen stark typisierte Domain-Objekte zu erstellen, basierend auf Sitecores Artikel.

(Edit 2011.09.13:. Benutzerdefinierte Artikel Generator funktioniert gut für diese http://blog.velir.com/index.php/2010/10/19/custom-item-generator/ )

Viel Glück.

Andere Tipps

Ich denke, die wirkliche Frage, die Sie hier stellen sollten, ist; wenn Sie bereits Sitecores an der richtigen Stelle - warum wollen Sie den Aufwand und complicatino MVC der Einführung

?

Haben Sie Geschäftsanforderungen außerhalb der grundlegenden Web-Site, die MVC erforderlich machen würde?

Ich zweite Mark Kommentar über die Anforderungen. Ist es das Risiko wert? Sie werden höchstwahrscheinlich die folgenden Features von Sitecores verlieren, wenn Sie sich nicht entscheiden nativen Rendering-Funktionalität zu verwenden:

  1. OMS
  2. Web Forms für Werbetreibende
  3. Bedingte Rendering
  4. Seite Editor
  5. Seite Designer

vielleicht sogar mehr.

Ich weiß, dass Sitecore Entwickler ASP.NET MVC betrachtet haben, aber ich weiß nicht, ob sie es versucht haben. Ich kann mich nicht von irgendwelchen Sitecores Projekten, die ich denke, hat von ASP.NET MVC profitieren würde. Die Sitecores dynamische Antwortmaschine, Rohrleitungen, Handler, Platzhalter und andere Merkmale scheinen einen Ober von dem, was Sie mit MVC erreichen können. Ähnliche Geschichte mit ASP.NET Masterseite -. Sie sie mit Sitecore nutzen könnten, aber Sitecores Layout Details sind überlegen

Ich bin nicht gegen ASP.NET MVC mit oder ohne Sitecore, aber Sitecores scheint die Eigenschaften eines Controllers zur Verfügung zu stellen (wirklich ASP.NET ist die Steuerung und Sitecores nur stöpselt), Informationsarchitektur ist das Modell, und Ihre Präsentationskomponenten sind die Ansichten.

Sie können sicher gemischt werden, und ich sicher, dass der Wert davon sehen :) Keine native Funktionalität wird mit dem Verfahren lossed ich in meiner Blog-Post beschreiben hier: http://www.chrisvandesteeg.nl/2012/02/26/sitecore- mvc /

Wie es der Zufall wollte, ich arbeite derzeit an zwei großen Projekten beide Technologien sind. Und während ich großer Fan von beiden bin, kann ich keine Vorteile sehen, um die beiden zu verschmelzen.

Was Sitecores geht, gibt es eine Lernkurve, aber ganz ehrlich in meinem Fall, da ich tatsächlich gelernt ASP.NET MVC „erste“, wie Web Forms Gegensatz hat sich die Lernkurve auch auf einige leicht zugeschrieben worden meine Unerfahrenheit mit Web Forms. Das heißt, immer noch da ist definitiv eine Lernkurve mit Sitecores beteiligt, aber es gibt viele Trainings- und Referenzmaterialien im Umlauf mit dem helfen. Auch der Web-Steuerelemente, die mit Sitecores kommen macht sie viel weniger das Gefühl, eine gerade Web Forms-Applikation erstellen. Außerdem gibt es die Möglichkeit für die Verwendung von XSLT als Rendering-Engine, die auch praktisch ist.

Wenn dies nur ein Projekt ist über Sie denken, würde ich sagen, nur Stick mit Sitecore als es das Präsentationssystem ganz gedacht ist gut. Und als Mark oben gesagt, wäre es wirklich kompliziert die Dinge ziemlich viel ich und ich bin auch nicht sicher, was es gibt sogar daraus zu gewinnen. Auch damit die Ansicht commodore73, Gebäude Sachen in der Sitecores ernst fühlt wie Sie MVC bereits verwenden, nur einen anderen Rahmen verwendet wird.

MVC in Sitecore hat das Potenzial, ist aber nicht Produktion bereit, denke ich. Sie bedecken unbekannten Boden, als ich entdeckte, als dies die Schaffung Blog-Artikel.

Ich weiß, dass dieser Beitrag ist ziemlich alt, aber ich dachte, ich würde meine Meinung zu Sitecores MVC sowieso geben. Ich habe angefangen, ein Projekt arbeiten, auf ein paar Monate zurück mit ausschließlich Sitecores MVC. Es gibt eine Menge von Einschränkungen, was ich mit arbeiten, da dieses Projekt mit oder ohne CMS arbeiten müssen und in der Lage sein, um fit in mit so vielen CMS wie möglich (wir derzeit 2 verwenden).

ASP.NET MVC war ein Klacks für uns. Es ist 2015, und wir müssen mit den neuen Technologien voran gehen. Wir verwenden Sitecores 8, und ich denke, dass Sitecore MVC mit Sitecore 7 reifen geworden ist.

Es gibt noch ein paar Unebenheiten auf der Straße though. Wenn Sie sich mit Sitecore mit FORMULARPLZ möchten, stellen Sie sicher, dass diejenigen verwenden AJAX gemacht. eine Validierung auf einem Feld tun kann schwierig sein, wenn Sie regelmäßig POST-Aktionen verwenden, aber es gibt Abhilfen.

Jetzt gibt es Habitat-Projekt.

Sitecores Habitat ist ein Sitecores Projekt, das die modulare Architektur bulit verwendet. In ihrer Website präsentieren sie ein voll funktionsfähiges Beispiel zu installieren und zu testen.

Habitat Projekt:

  

https://github.com/Sitecore/Habitat

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top