SharePoint Layered Architecture App

Question

Verwenden Sie Enterprise Layer -Architektur beim Erstellen von SharePoint -Lösungen? Können Sie mir ein Codeplex.com/other -Site -Projekt als Beispiel geben, bei dem ich ein geschichteter Design finden kann? (Schnittstelle/bl/dal)

Answer 1

Ich verwende Layered Architecture in all meinen SharePoint -Lösungen und behandle SharePoint im Allgemeinen als UI -Schicht, um sie sehr dünn zu halten. Jede Logik geht in das Geschäftsmodell ein, und ich habe Dal -Wrapper, um die Listeninfrastruktur abstrahieren (was auch beim Testen hilft).

Für eine gute Lektüre über geschichtete Architektur in ASP.NET finden Sie diesen Artikel hier. Es ist ASP.NET und NhiNRNATE, aber die Prinzipien sind gleich. Es gibt auch eine geschichtete Architektur -Probe in .NET hier auf Codeplex. Auch hier sind nicht sharePoint -spezifisch, aber die Prinzipien sind gleich.

Halten Sie die SharePoint UI dünn und widerstehen Sie der Versuchung, in Listen in Ihrem Web -Teil -Code zu lesen/zu schreiben. Behandle es wie eine Datenbank (weil es ist!)

Answer 2

Stimme bil zu.

Web -Teile, Websteuerelemente, Anwendungsseiten usw. sollten nur die UI -Ebene sein, die in eine Ebene aufruft, die des ursprünglichen Aufrufkontexts agnostisch ist. Das Aufrufen von Kontext kann ein Ereignisempfänger, eine Konsolenanwendung, einen Timer -Job, einen Workflow usw. sein. Stellen Sie immer sicher, dass diese gemeinsame Ebene, in die Sie anrufen, keine Abhängigkeit von spcontext.current hat, da sie nicht immer da ist! Akzeptieren Sie SPWEBs, Splisten, Splisitems usw. als Methodenparameter und Konstruktorparameter. In einem Webkontext können Sie diese vom Spcontext.current übergeben, aber in einer Konsolenanwendung würden Sie diese selbst konstruieren.

Um die einfache Debuggierung zu verbessern (nur F5 drücken) und den Entwickler -Feedback -Zyklus verkürzen, beginne ich häufig mit dem Schreiben einer einfachen Konsolenanwendung, die in die Ebene aufruft, die die Kernlogik enthält, und ein SPWEB, das ich in der Konsolenanwendung aufgebaut habe, übergibt. Sobald die Kernlogik fertig ist, schreibe ich ein dünnes Webcontrol oder WebPart, um die Konsolen -App zu ersetzen, den SPWEB aus dem Kontext, anstatt sie zu konstruieren, Ereignishandler usw. einrichten usw.

Answer 3

Zu bil und jaap (oder jemand anderem),

Ich frage mich, welche Art von Objekten/Schnittstellen Sie zwischen den Schichten übergeben. Geben Sie ein SplistItem zurück oder geben Sie eine Art Schnittstelle zurück, die das SplistItem darstellt?

SharePoint ist ein seltsames Tier, da der Benutzer tatsächlich die Möglichkeit hat, die Datenstruktur über die Webschnittstelle zu ändern (er kann Spalten in einer Liste hinzufügen/entfernen/ändern). Wenn Sie ein Objekt/eine Schnittstelle zurückgeben, müsste jedes Mal, wenn eine Liste von einem Benutzer geändert wird, der Code neu kompiliert (und bereitgestellt), um die neue Spalte (Eigenschaft) aufzunehmen. Wenn Sie das SplistItem zurückgeben, brechen Sie die Schicht, indem Sie den direkten Zugriff auf die Datenquelle (SharePoint) ermöglichen.