Download (2271Kb) - HSR - Institutional Repository

Weitere Magazine

Empfehlungen

Info

SURVEAST – Technologiestudie mit SharePoint8.2.4. External ListsExterne Listen müssen erstellt werden um über das Silverlight Client Object Model auf den BCSzugreifen zu können (siehe 7.2.3).8.2.5. SURVEAST Domain ConnectorDie Klassen im Namespace Surveast.Domain.Connector kümmern sich um das Laden der Daten übereine externe SharePoint Liste und den Business Connectivity Service und trennen den Domain Layervom Datenprovider (BCS).Das folgende Beispiel zeigt den Vorgang am Beispiel des Ladens von Patienten über eine externeSharePoint Liste (pl : PatientList).Abbildung 18: Beispiel Ablaufdiagramm für einen Abruf von Daten mit dem ConnectorDatum: 23-12-2010 Clemens Meier & Silvan Gacond Seite: 36 von 79
SURVEAST – Technologiestudie mit SharePoint8.2.6. SURVEAST DomainAbbildung 19: Übersicht Domain LayerDer Domainlayer wurde für das Pilotmodul so einfach wie möglich gehalten. Ereignisgruppen werdennur noch durch eine Angabe im Eventtypen (EventType) unterschieden. Durch Anfügen weitererSpecificEvents (von Event abgeleitete Klassen) kann das System für zukünftige Erfassungen undAuswertungen erweitert werden. Allerdings müssen dafür alle weiteren Schichten unterhalb desDomainlayers (Domain.Connector, Externe Listen, BDCModel und Stored Procedures auf derDatenbank) auch angepasst werden.8.2.7. Silverlight WebpartDer WebPart dient grundsätzlich dazu das Silverlight XAP-File zur Verfügung zu stellen, damit diesvom Browser geladen werden kann. Dazu wird der SharePoint eigene, generische Silverlight Webpartverwendet und entsprechend konfiguriert.8.2.8. Silverligth UIGemäss dem MVVM Pattern wird für XAML-Technologien wie Silverlight oft die Logik der Views ineine weitere Zwischenschicht gekapselt. Dieses ViewModel wird dann direkt als DataContext an dieView gebunden. Dazu muss es das INotifyPropertyChanged Interface implementieren, damit allfälligeÄnderungen direkt an die anderen Schichten weitergereicht werden können.Wichtig hierbei ist, dass die View-Controls, welche per DataBinding ans ViewModel gebunden sind,bei jeder Änderung den PropertyChanged Event auslösen. Die Daten sollten aber nicht bei diesemEvent persistiert werden, sonst hat einerseits der Benutzer die Kontrolle über die Persistierung(„Save/Discard“) verloren und andererseits wird viel teilweise ungewollter Traffic zum SharePointverursacht.Interaktionen die vom Benutzer ausgelöst werden (z.B. Button-Clicks), werden mit dem sogenanntenCommandBinding realisiert. Dazu wird eine im ViewModel eingebettete Klasse verwendet, die dasICommand Interface implementiert. Diese wird dann im XAML Code an das entsprechendeSteuerelement gebunden. So ist das gesamte ViewModel mit allen Interaktionen von aussenautomatisiert testbar (siehe 8.3).Datum: 23-12-2010 Clemens Meier & Silvan Gacond Seite: 37 von 79
Seite 1 und 2: SURVEASTTechnologiestudie mitShareP
Seite 3 und 4: SURVEAST - Technologiestudie mit Sh
Seite 35: SURVEAST - Technologiestudie mit Sh
Seite 63 und 64: 5 Dokumentation5 DokumentationSURVE
Seite 75 und 76: Woche 1Woche 2Woche 3Woche 4Woche 5
Seite 77 und 78: Woche 14Woche 1Woche 2W3Woche 4SURV
Seite 79: Woche 14SURVEAST - Technologiestudi

Download (2271Kb) - HSR - Institutional Repository

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?