Die Bewertung von Sharepoint vs ASP.NET als Entwicklungs-Plattform

Ich bin die Bewertung von Sharepoint (nicht MOOS) vs ASP.NET als Entwicklungs-Plattform für eine bevorstehende Lösung für unser team. Wir werden eine Lösung entwickeln, die für die Breite (hoffen wir) - Bereitstellung in einer Vielzahl von Umgebungen. Ich bin die Identifizierung Kategorien zur Bewertung vor - /Nachteile für die einzelnen Plattform-Wahl. Ich habe Kategorien, die für unsere Anforderungen und die Auswirkungen auf Entwickler - /tester Produktivität. Kann jemand denken, der alle anderen Kategorien, das wäre für einen Vergleich? Kann jemand irgendwelche Details über Ihre Erfahrungen mit den beiden Plattformen mit Bezug auf jede der Kategorien?

Einige andere Informationen, wir haben eine kurze zwei-Monats-Zeitraum zum release etwas, so dass wir die Priorisierung von features, wie wir sprechen. Wir sehen Sharepoint als einen Weg, um etwas zu bekommen, aus der Tür schnell, während die Nutzung der UI-framework für eine grundlegende UI -, Sicherheits -, und Listen und Dokument-Bibliotheken für die Lagerung.

    Entwicklungsumgebung
    Produktivität Der Entwickler
    Funktionale Testbarkeit
    Entwickler Testbarkeit (unit-Tests)
    Rolle Sicherheit
    View-basierte Security -
    User Experience
    Datenbank - Einfache Entwicklung mit Sharepoint basiert auf der Verwendung von Listen. Jedoch, das hinzufügen von reporting als Voraussetzung macht mit Listen ein hinderance.
    Reporting - Sharepoint macht dies schwierig
    Dokument-Repository - Unsere Lösung erfordert mehrere Dokumentbibliotheken zu befestigen Artefakte zur Lösung Elemente
    Verpackung
    Installation - Sharepoint bietet uns einfach famr installation über WSP.
    Skalierbarkeit
    Erweiterbarkeit
    Komplexität
    Konzeptionellen Integrität (Domänengrenzen)

Redundanz/Replikation/Backup - /Recovery-Unterstützung

InformationsquelleAutor Pete Maroun | 2009-04-15
  1. 1

    Offiziell, um die Entwicklung der WSS-Lösungen, die alle Ihre Entwickler benötigen, um Ihre Entwicklungsumgebung ausführen auf einem WSS-server. Ich halte das für eine negative.

    Siehe die vielen Kommentare unter Sharepoint-tools-Unterstützung in Visual Studio von Somasegar.

    Ich würde sagen, da haben Sie eine kurze Frist, Sie betrachten auch die Tatsache, dass es ist eine viel kleinere SharePoint-Entwickler-community als es ASP.NET community. Vergleichen Sie die Anzahl der Artikel auf SO getaggt mit "ASP.NET" im Gegensatz zu denen mit dem Stichwort "SharePoint".

    Ich würde gehen mit ASP.NET in der kurzen Frist, zu verstehen, dass Sie möglicherweise in der Lage umgestalten Ihrer Anwendung für die Verwendung von SharePoint auf längere Sicht. Verwenden Sie eine Datenbank-Struktur, ähnlich wie die Liste oder in anderen content-Typen, die Sie erstellt haben in SharePoint. Halten Sie ein ähnliches Modell für die Bereitstellung. Fühlen Sie sich frei, um den workflow nutzen, aber es sollte wohl parallel zu den workflow-Funktionen von SharePoint. Man könnte sogar das Layout Ihrer Seiten in einer ähnlichen Weise. Dadurch wird es einfacher, sich zu bewegen, zu SharePoint, wenn Sie mehr Zeit haben.

    • Danke, John ... ich update die Werkzeug-Kategorie zu reflektieren, die Entwicklung der Umwelt. Wir haben bereits unsere Entwicklungsumgebung provioned (Win2k8 Böen in HyperV mit Sharepoint / VS.NET und TFS-Zugriff).
    • Ich habe ehrlich gesagt nicht Zustimmen. Wenn Sie sich nicht aktiv an der Entwicklung für SharePoint, und erwarten, um in der Lage zu migrieren asp.net Artefakte/code in einer nahtlosen Art und Weise; Sie werden sehr enttäuscht.
    • Bitte lese meine Antwort noch einmal. Ich sagte ihm, zu verwenden ASP.NET anstelle von SharePoint.
    InformationsquelleAutor John Saunders
  2. 5

    Sehe ich nicht Kosten.

    • Kosten würde die Folge sein, viele der Auswertungen von oben.
    InformationsquelleAutor Srikar Doddi
  3. 3

    Ist Ihre Lösung gehen, um etwas zu tun, collaboration oder web content management? Wenn nicht, hinzufügen von SharePoint in den mix ist nicht immer eine fantastische Idee.

    Mit WSS 3.0 als Entwicklungsplattform statt ASP.NET würde erfordern einige ernsthafte Rechtfertigung, und es ist nicht möglich zu sagen, aus Ihrem begrenzten Beschreibung der Lösung, warum würden Sie sogar erwägen, die.

    Auf alle Ihre mess-Aspekte, erstellen der Entwicklung auf der SharePoint-Plattform hinzufügen würde coplexity und daher die Kosten für Entwicklung bemühen.

    Update

    Sehe ich die Sharepoint-Sicherheit, Dokumenten-Bibliotheken, UI-framework, und
    das fehlen von mit zu konstruieren und
    test DB als große productivty
    Enhancer. Diese sind Sharepoint
    Funktionen, können wir stark profitieren
    von

    Die Vorteile von SharePoint für diese Elemente werden weit aufgewogen durch die Kosten-Aspekte des Lernens, die Programmierung und die Unterstützung von SharePoint. ASP.NET einfache Lösungen für diese Elemente, und in einem viel mehr überschaubar. Nach beiden Produkte, die Sie möchten, bleiben Sie mit ASP.Net

    Denken Sie daran, dass SharePoint-Listen nicht jede Art von relationalen Integrität schaffen so etwas mehr als eine triviale Beziehung zwischen in SharePoint-Listen wird am Ende Massiv teurer als die Erstellung eines join-Anweisung und ein paar gespeicherte Prozeduren.

    Ohne zu wissen, mehr details zu dem Projekt, ich kann nicht völlig ausschließen, SharePoint, als eine Lösung.

    Es ist zwar möglich mit SharePoint als Entwicklungsplattform, wenn Sie nicht über SharePoint-Experten arbeiten mit Ihnen, das könnte Ihre Frage beantworten, Sie haben nicht genug SharePoint-Fähigkeiten, die Ihr Projekt zu einem Erfolg machen.

    • Wir sind nicht mit web-content-management (MOSS wird nicht ausgewertet) und der Zusammenarbeit ist keine Voraussetzung, die außerhalb der mit einer docuemnt-Bibliothek.
    • Ich sehe die Sharepoint-Sicherheit, Dokumenten-Bibliotheken, UI-framework, und der Mangel an Aufbau und test einer DB als große productivty Enhancer. Diese sind Sharepoint-Funktionen, wir können stark davon profitieren.
    InformationsquelleAutor Nat
  4. 1

    Skalierbarkeit

    Lizenz-Einschränkungen

    Erweiterbarkeit

    Komplexität

    Konzeptuelle Integrität (Domänengrenzen)

    Vendor Lockin/Open-Systems-Support

    Redundanz/Replikation/Backup - /Recovery-Unterstützung

    • Ich denke, Sie sollten entweder erarbeiten diese Parameter oder atleast bieten relative Indikatoren für jede option.
    • Ich würde gerne, aber es gibt nicht genug Kontext, in der Frage selbst bestimmen deren relative Bedeutung. Ich denke, es wird eine Herausforderung, zu dieser Bewertung sinnvoll (obwohl ich kann Ihnen helfen, füllen Sie die Checkliste.)
    • Für eine Sache, es sollte evaluiert werden, zunächst als eine Plattform zur Auslieferung, keine Weiterentwicklung der Plattform. Es ist nicht einmal klar, dass Sie verwendet werden sollen, die gleiche Sache, obwohl ich denke, dass es wahrscheinlich.
    InformationsquelleAutor dkretz
  5. 0

    Verwenden wir SharePoint als eine Komponente für die meisten Anwendungen, die wir bauen, für seine Fähigkeit zum erstellen und verwalten von Listen und Inhaltstypen (und auto-CRUD), Versionierung, Berechtigung Modell und workflow-tools.

    Entwickelten wir-SLAM -, SharePoint-Liste Vereins-Manager, zur überwindung der offensichtlichen Einschränkungen in Bezug auf SharePoint-Daten nicht relational. Da schiebt er die SharePoint-Daten SQL Server, erlaubt es uns, die Verwendung von SharePoint nur auf das "backend" mit nur ASP.NET auf dem front-end, eine Konfiguration, die wir Häufig verwenden.

    Die wir veröffentlicht haben-SLAM eine open-source-Projekt, so dass der rest der Entwickler-community, können die Vorteile dieses Konzepts und helfen Sie uns, erweitern.

    http://slam.codeplex.com

    Gerne Zuschlagen!

    Allan

    InformationsquelleAutor
Schreibe einen Kommentar