Wechsel von benutzerdefinierten ASP.NET-Anwendung zu Sharepoint Services

Question

Unser Unternehmen verfügt über eine ASP.NET-Anwendung für Kundendatenbank. Die Anwendung begann klein, aber ohne richtiges Design gewachsen. Jetzt sollte eine neue Version der App entwickelt werden, was im Grunde bedeuten würde, sie von Grund auf zu entwickeln und zu implementieren. Das Unternehmen ist daran interessiert, Microsoft Sharepoint Services in Zukunft zu nutzen, und es wurde vorgeschlagen, es mit dieser Kundendatenbankanwendung zu testen.

So ist meine Fragen:

Ist Datenbank getriebene Anwendung etwas WSS für gut? Meistens würde die App CRUD-Operationen in der Datenbank durchführen und auch Berichte erstellen.

Answer 1

Ich stimme Greg darin zu, dass ich nicht empfehlen würde, Ihre Daten in SharePoint-Listen zu setzen (das ist, was Greg annehmen könnte). Aber meine kurze Antwort wäre "vielleicht".

Hier ist die lange Antwort ...

Sharepoint läuft auf ASP.NET so sollte es Ihre Bedürfnisse anzupassen. Sie schreiben wahrscheinlich ASP.NET-Webseiten, die in SharePoint gespeichert sind, die auf Ihre Datenbank zugreifen, oder schreiben Webparts in SharePoint, die auf Ihre Datenbank zugreifen.

Sie könnten den BDC zum Lesen/Abrufen von Daten in Betracht ziehen, aber das erfordert MOSS Enterprise und stellt den CUD-Teil von CRUD nicht zur Verfügung. Andere Tools wie CorasWorks DIT können helfen, aber ich vermute, dass benutzerdefinierte Webparts oder Seiten der richtige Weg für Sie sind.

Es gibt viele Vorteile, die Sie von SharePoint erhalten können, wie Autorisierung und vielleicht Dinge wie die Integration Ihrer Daten mit SharePoint-Listendaten, Provisionierung, Suche, etc. Es hängt wirklich von der Art Ihrer Anwendung ab, ob SharePoint wird bieten einen großen Vorteil.

Answer 2

Kurze Antwort: Nein.

Lange Antwort: Gibt es eine Zusammenarbeit? Unterstützende Dokumentation für die Daten? Arbeitsablauf? Wenn nein, dann gibt es wirklich keinen Grund, es über SharePoint zu hosten - Sie werden nicht viel gewinnen.

Zusätzlich berücksichtigen, dass die Sharepoint-Listen wie Tabellen aussehen, aber sie sind nicht - es gibt keine relationale Aspekte der Listen - keine Verbindung, keine Kaskadierung updates/löscht, usw. Dies kann ein Problem sein, wenn Datenberichte einen großen Teil Ihrer App ausmachen.

Sie können die Daten extern speichern und sie als schreibgeschützte Listen in SharePoint anzeigen lassen, aber Sie springen immer noch durch viele Ringe, wenn Sie keine der anderen SharePoint-Funktionen verwenden.

Answer 3

Kirk schlug mich und Punsch sagte, es besser als ich ohnehin hätte :)

Eine andere Sache zu prüfen, ist die Möglichkeit der Arbeitsabläufe in Ihrem Prozess. Wenn Sie beispielsweise einen Prozess starten müssen, wenn ein neuer Kontakt hinzugefügt wird (ein Folgeanruf usw.), bietet SharePoint eine Menge Vorteile.

Vielleicht wäre eine Hybridlösung angemessen. Eine benutzerdefinierte App für Ihre CRUD- und SharePoint-Integration für die Teile, die Sinn und Wert bieten.

In SP für SP zu bauen ist wahrscheinlich keine gute Idee.

Answer 4

Wir haben einen ASP.NET-Anwendung, die in MOSS 2007 läuft. Obwohl wir kaum Funktionen von SharePoint nutzen, haben wir den Vorteil von SharePoint Sicherheitsmodell, Navigation Webparts (wir verwenden CorasWorks), integrierte Reporting Services und Workflows. Zumindest sind SharePoint-Funktionen für uns eines Tages zu verwenden.

Alle unsere Anwendungsdaten befinden sich in einer eigenen SQL Server-Datenbank. Wir speichern nichts in der SharePoint-Inhaltsdatenbank.