Hinterlasse einen Kommentar

SharePoint als Datenbank für Web-Entwickler

Als Web-Entwickler beginnt jedes Projekt mit einem ähnlichen Ablauf: sobald das Konzept steht, wird zuerst die Datenbank ausgearbeitet, ein Prototyp erstellt und dann kommt die Admin-Oberfläche, wo der Anwender seine Daten pflegen kann. Dieser Arbeitsschritt – nämlich die Oberfläche für die Daten-Bewirtschaftung ist immer sehr ähnlich, aber die kleinen Unterschiede machen viele Stunden Arbeit – meist unbezahlte Stunden, weil „es ja klar ist, dass es so sein muss“ – wer kennt das nicht🙂.

Bei jedem Gespräch mit Entwickeln kommen immer viele Lösungen für das Problem, jedoch hat keiner eine wirklich funktionierende. Typische Ansätze sind:

  1. Dynamic Data vom .net Framework – noch nicht ausgereift und jede kleinigkeit muss dazuprogrammiert werden, was besonders bei kleinen Projekten das Budget sprengt
  2. Standard-Tools wie Telerik RadGrid – ausgereift, aber funktioniert nur in den einfachsten Fällen; komplexere Fälle geben überdimensional viel Arbeit
  3. Standard DB-Oberflächen-Tools: Nett, meist gut, aber sehen schlimm aus + sind meist verwirrend, da der Anwender nicht in Datenbank-Schemen denkt; Ausnahmen wieder aufwändig
  4. Übernormalisierte DB-Systeme (beispiele aus DotNetNuke sind Form and List sowie XMod): nett, aber wieder zu speziell

Bei all diesen Punkten kann man sagen: Nett, für einfache Probleme toll, aber schon leicht komplexere Fälle verursachen überdimensional viel Arbeit, und auch nur so lange, wie der Kunde beispielsweise keine Versionierung wünscht – dann wirds hässlich. Und spätere Änderungen – die meist schon während des Projekts beginnen – sind mit viel Folgeaufwand verbunden.

SharePoint zur Rettung

Wir versuchen jetzt einen anderen Weg: wir werden die nächsten Projekte so aufbauen, dass SharePoint die Datenbank ist. Das ist richtig, SharePoint wird die Datenbank, in der der Kunde alles bewirtschaftet, betreut, usw. Das Front-End greift dann auf diese DB zu (selbstverständlich über eine der verwirrenden APIs wie REST, SOAP, Client-Object-Model etc.) und produziert lediglich noch den Output.

Wir erhoffen uns daraus viele Vorteile, insbesondere:

  1. eine viel raschere Initialumsetzung
  2. viel mehr Flexibilität (neues Feld? kein Problem, ist sofort gemacht! Das Feld muss aus einer andere Liste kommen, kein Problem – klick-klick)
  3. eine saubere, professionelle Oberfläche out-of-the-box
  4. Versionierung :)!
  5. Geschenkte Medienablage für PDFs, Bilder, usw.

Eure Meinung?

Was denkt ihr? Habt ihr das schon mal so gemacht? Eure Meinung & Erfahrung würde mich brennend interessieren.

Über iJungleBoy

Missionary Kid, Entrepreneur, Software Developer, DotNetNukeer, SharePoint-Fanatic and InfoPath-Lover.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: