Verwenden von Silverlight und des Clientobjektmodells für den Zugriff auf SharePoint Server 2010-Daten (Wrox)
Inhaltsverzeichnis reduzieren
Inhaltsverzeichnis erweitern

Verwenden von Silverlight und des Clientobjektmodells für den Zugriff auf SharePoint Server 2010-Daten (Wrox)

SharePoint 2010

Zusammenfassung: Informationen zum Erstellen von Microsoft Silverlight-Anwendungen für Microsoft SharePoint 2010 mithilfe des Clientobjektmodells sowie zum Verwenden von Silverlight zum Laden, Bearbeiten und Aktualisieren von SharePoint-Daten über die Clientobjektmodell-API.

Wrox-Logo

Wrox SharePoint Books

Letzte Änderung: Montag, 9. März 2015

Gilt für: Business Connectivity Services | Open XML | SharePoint | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Inhalt dieses Artikels
Einführung in die Verwendung von Silverlight und des Clientobjektmodells für den Zugriff auf SharePoint 2010-Daten
Einführung in das Clientobjektmodell
Abrufen von Daten über das Clientobjektmodell
Umwandeln von Daten in Objekteigenschaften
Binden einer Ansicht an das Ansichtsmodell
Übermitteln von Änderungen an Daten
Informationen zum Autor
Weitere Ressourcen

Autor: Ryan Morgan

Redaktion: Technische Redakteure bei WROX für SharePoint 2010-Artikel

Inhalt

Das begleitende Codebeispiel bietet ein funktionierendes Beispiel für die Implementierung eines Modellansichtsprojekts vom Typ ViewModel zum Verwalten von SharePoint 2010-Daten. Es enthält außerdem Code, den Sie in ähnlichen Projekten nutzen können, um Funktionalität zum Rückgängigmachen bereitzustellen.

Code herunterladen

In diesem Artikel wird anhand des folgenden Szenarios das Erstellen von Silverlight-Anwendungen in SharePoint 2010 mithilfe des Clientobjektmodells erläutert.

Die Marketingabteilung von Adventure Works nutzt zum Verwalten ihrer Ressourcen eine SharePoint-Teamwebsite. Das Team hat sich entschieden, die Benutzerumgebung zu verbessern und eine umfassendere Benutzeroberfläche bereitzustellen. Die Mitglieder arbeiten derzeit mit Silverlight, um genehmigte grafische Ressourcen für ihre Produkte zu durchsuchen und zu verwalten. Mitarbeiter der Marketingabteilung nutzen SharePoint-Workflows und eine Aufgabenliste zum Erstellen neuer Anforderungen von Ressourcen an das Grafikdesignteam. Nachdem das Grafikdesignteam die Ressource übermittelt hat, wird ihr Inhalt zunächst vom Marketingteam und anschließend von der Rechtsabteilung geprüft, ehe die Ressource einem größeren Nutzerkreis als genehmigte Version zur Verfügung gestellt wird. In einem einfachen sequenziellen in Visual Studio vordefinierten Workflow wird die Ressource nach Angabe des Datum der Genehmigung durch die Rechts- und Marktingabteilung als genehmigt markiert. Das Beispiel in diesem Artikel hat einen Ansichts- und Bearbeitungsmodus für Ressourcen in der Ressourcenliste und verwaltet die Elemente in dieser Liste mithilfe der Clientobjektmodell-API.

Bevor Sie diesen Artikel lesen, sollten Sie bereits grundlegend damit vertraut sein, wie das ClientContext-Objekt Daten lädt und Änderungen an Daten übermittelt werden.

Die Clientobjektmodell-API ist neu in SharePoint 2010 und ermöglicht den Zugriff auf und die Verwaltung der Websites und Inhalte von SharePoint 2010-Anwendungen. Im Gegensatz zu früheren SharePoint-Versionen sind keine Kenntnisse der SOAP-Webdienste zum Erstellen einer Anwendung erforderlich, da die Bibliothek alle Aufrufe an den WCF-Dienst mithilfe einer stark typisierten API abstrahiert, die nahezu so wie das Serverobjektmodell funktioniert. Mithilfe dieser API können Sie mit einer SharePoint-Remoteinstanz arbeiten und eine Formatvorlage verwenden, mit der Sie vertraut sind, sofern Sie benutzerdefinierte Webparts oder Dienste in SharePoint entwickelt haben.

Wenn Sie mit dem Serverobjektmodell für die SharePoint-Entwicklung vertraut sind, sind Ihnen viele der Namespaces und Vorgänge vertraut. Tabelle 1 enthält mehrere SharePoint-API-Namespaces und die entsprechenden Namespaces im verwalteten Clientobjektmodell.

Tabelle 1

Serverobjektmodell

Clientobjektmodell

SPContext

ClientContext

SPSite

Site

SPWeb

Web

SPUser

User

SPList

List

SPListItem

ListItem

SPField

Field

Das Wesentliche, was es zu beachten gilt, wenn Sie von der Programmierung mit dem Serverobjektmodell zur Entwicklung von Silverlight-Anwendungen mit dem Clientobjektmodell wechseln, ist, dass Silverlight auf dem Client ausgeführt wird. Aufgrund dieser einfachen Tatsache ergeben sich die folgenden wichtigen Unterschiede:

  • Das Clientobjektmodell bietet nicht das Konzept des aktuellen Kontexts, den das SPContext.Current-Objekt bereitstellt. Das ClientContext-Objekt wird mit einem Parameter des SharePoint-Web-URI instanziiert, mit dem eine Verbindung hergestellt werden soll.

  • In Silverlight sind alle Aufrufe an den Server asynchron. Unabhängig davon, ob die ClientContext.Load-Methode aufgerufen wird, kann erst auf die Daten zugegriffen werden, nachdem die ExecuteQueryAsync-Methode aufgerufen wurde. Im folgenden Beispiel stehen die geladenen Objekte oder Abfragen erst zur Verfügung, nachdem die OnQuerySucceeded-Methode aufgerufen wurde. Die OnQuerySucceeded-Methode wird für eine erfolgreiche Abfrage als Rückrufhandler registriert, wenn der asynchrone Aufruf von der ExecuteQueryAsync-Methode zurückgegeben wird.

  • Es gibt keine Möglichkeit, den Code mit erhöhten Berechtigungen auszuführen.

Über das ClientContext-Objekt wird der gesamte Zugriff auf SharePoint-Serverdaten bereitgestellt. Das ClientContext-Objekt überwacht den Status von ListItems-Elementen, bietet Batchbefehle für Aufrufe an SharePoint und ermöglicht sämtliche Aufrufe an die Clientobjektmodell-API.

Das folgende Codebeispiel zeigt, wie der Inhalt einer Liste mithilfe von C# und des Clientobjektmodells geladen wird. Zur Verkürzung wird die Fehlerbehandlung nicht explizit gezeigt, und Fehler während der Abfrage werden an die Standardfehlerbehandlung im Silverlight-Projekt übergeben. Bewährte Vorgehensweisen für die Protokollierung und Behandlung von Ausnahmen finden Sie in der Enterprise-Bibliothek für Silverlight.

public HomeViewModel()
{
// First - instantiate the Assets Web.
// Note that SharePointSiteURI resolves to "http://sl2sp.local/".
AssetsContext = new ClientContext(AppViewModel.Instance.SharePointSiteURI); 
            
// Queue the call to load the web. 
AssetsContext.Load(AssetsContext.Web);

// Build the CAML query used to select the data. 
// In this case, simply select all fields. 
CamlQuery qry = new CamlQuery();
string strQuery = "<View/>";
qry.ViewXml = strQuery;

// Query the list by loading a query for the ProductAssets list. 
ProductAssetsListItems = AssetsContext.Web.Lists.GetByTitle("ProductAssets").GetItems(qry);

// Mark the query for loading by the AssetsContext. 
AssetsContext.Load(ProductAssetsListItems);

// Run the query, and assign the return method.
AssetsContext.ExecuteQueryAsync(onQuerySucceeded, onQueryFailed);
}

private void onQuerySucceeded(object sender, ClientRequestSucceededEventArgs args)
{
// Because the AssetsCount property is bound in the UI, the Dispatcher 
//  for the UI thread should be used when assigning a value to it. 
AppViewModel.Instance.AppDispatcher.BeginInvoke(
    () =>
    {                    
        AssetsCount = ProductAssetsListItems.Count; 
    }
    );
}

private void onQueryFailed(object sender, ClientRequestFailedEventArgs args)
{
    //Bubbles the error message up. This will
    // be caught by the unhandled exception handler in App.XAML.
    throw new Exception(string.Format("Query failed  with message {0}", args.Message));
}

Wenngleich einfach, veranschaulicht das vorherige Beispiel viele der zuvor beschriebenen wesentlichen Aspekte. Das ClientContext-Objekt wird mit der URL für die Website geladen, für die es ausgeführt wird, und eine asynchrone Rückrufmethode wird nach Beendigung der Abfrage auf den Rückgabewert angewendet. Falls Code versucht, auf die Eigenschaften des Web- oder List-Objekts zuzugreifen, bevor der Aufruf von ExecuteQueryAsync erfolgt ist, wird eine Ausnahme vom Typ NotInitialized ausgelöst.

Nun da Sie mit den Grundlagen des ClientContext-Objekts und dem Zugriff auf Daten aus SharePoint vertraut sind, können Sie mit dem Marketingbeispiel fortfahren. Abbildung 1 zeigt die Oberfläche, die das Team zur Produktverwaltung entworfen hat.

Abbildung 1. Benutzeroberfläche zur Produktressourcenverwaltung

Schnittstelle für Product Asset Management

Listen- und Bibliotheksdaten, die von der Clientobjektmodell-API zurückgegeben werden, haben die Form eines schwach typisierten Wörterbuchs. Um in den Genuss des leistungsstarken Bindungsmodells zu kommen, das in Silverlight-Anwendungen zur Verfügung steht, müssen Entwickler die Objekte und Eigenschaften manuell erstellen, um die Daten in SharePoint-Listen auf der Silverlight-Benutzeroberfläche abzubilden. Auf dieser Oberfläche können die Details zu einer Produktressource bearbeitet werden. Zum Abbilden dieser Daten als stark typisierte Objekte, die an Steuerelemente in der Ansicht gebunden werden können, benötigt die Anwendung die folgenden Objekte:

  • Ein Objekt zum Abbilden der Nachschlageliste für Kategorien

  • Ein Objekt zum Abbilden der Nachschlageliste für Produkte

  • Ein Objekt zum Abbilden der Produktressourcen, die mit der Anwendung verwaltet werden

Da alle der genannten Objekte ein SharePoint-Objekt vom Typ ListItem abbilden, müssen Sie zunächst eine Basisklasse erstellen, von der alle drei Objekte erben können. Es folgt die Definition der SharePointEntityBase-Klasse.

public class SharePointEntityBase : ObservableObjectBase
{
public ListItem SourceItem { get; set; }
public int? Id
{
get
{
if (SourceItem != null)
    return SourceItem.Id;
else
    return null;
}
}
public void UpdateSourceItem(string fieldName, object value)
{
if (!IsLoading)
{
if (SourceItem != null)
{
    SourceItem[fieldName] = value;
}
HasChanges = true;
}
} 
}

Zunächst erbt die Klasse von der Basisklasse ObservableObjectBase, die die INotifyPropertyChanged-Schnittstelle implementiert. Diese Klasse bietet die Funktionalität zum Auslösen von PropertyChanged-Ereignissen, die Bindungen ermöglichen (siehe den herunterladbaren Quellcode). Die Eigenschaft in der Basisklasse dienen zum Verwalten des ListItem-Objekts, dem die abgeleiteten Klassen zugeordnet sind. Die SourceItem-Eigenschaft behält die ListItem-Instanz bei, die zum Laden des Objekts aus SharePoint genutzt wurde. Da das ClientContext-Objekt den Status eines ListItem-Objekts nachverfolgt, ermöglicht das Beibehalten eines Verweises auf das ListItem-Objekt den Objekten, die davon erben, die automatische Aktualisierung des zugrunde liegenden Felds im ListItem-Objekt.

Nach Erstellen der Basisklasse muss im nächsten Schritt die Klasse zur Aufnahme der ProductAsset-Eigenschaften erstellt werden. Es folgt die Definition der ProductAsset-Klasse.

public class ProductAsset : SharePointEntityBase
{
public string FileName
{
get { return _FileName; }
private set
{
    _FileName = value;
    NotifyPropertyChanged(_FileNameChangedEventArgs);
}
}
private string _FileName;
private PropertyChangedEventArgs _FileNameChangedEventArgs = new PropertyChangedEventArgs("FileName");

public string FileType
{
get { return _FileType; }
private set
{
    _FileType = value;
    NotifyPropertyChanged(_FileTypeChangedEventArgs);
}
}
private string _FileType;
private PropertyChangedEventArgs _FileTypeChangedEventArgs = new PropertyChangedEventArgs("FileType");

public Product AssociatedProduct
{
get { return _AssociatedProduct; }
set
{
    _AssociatedProduct = value;
    NotifyPropertyChanged(_AssociatedProductChangedEventArgs);
    if (value != null)
        UpdateSourceItem("Product", value.Id);
    else
        UpdateSourceItem("Product", null);
}
}
private Product _AssociatedProduct;
private PropertyChangedEventArgs _AssociatedProductChangedEventArgs = new PropertyChangedEventArgs("AssociatedProduct");

public DateTime? LegalApprovedDate
{
get { return _LegalApprovedDate; }
set
{
    _LegalApprovedDate = value;
    NotifyPropertyChanged(_LegalApprovedDateChangedEventArgs);
    UpdateSourceItem("LegalApprovedDate", value);
}
}
private DateTime? _LegalApprovedDate;
private PropertyChangedEventArgs _LegalApprovedDateChangedEventArgs = new PropertyChangedEventArgs("LegalApprovedDate");

public DateTime? MarketingApprovedDate
{
get { return _MarketingApprovedDate; }
set
{
    _MarketingApprovedDate = value;
    NotifyPropertyChanged(_MarketingApprovedDateChangedEventArgs);
    UpdateSourceItem("MarketingApprovedDate", value);
}
}
private DateTime? _MarketingApprovedDate;
private PropertyChangedEventArgs _MarketingApprovedDateChangedEventArgs = new PropertyChangedEventArgs("MarketingApprovedDate");
}

Für bearbeitbare Eigenschaften steht ein Aufruf zum Aktualisieren des Quellelements im Setter der Eigenschaft zur Verfügung. Über diesen Aufruf wird das zugrunde liegende ListItem-Objekt aktualisiert. Wenngleich in diesem Artikel nicht behandelt, ist für die bearbeitbaren Eigenschaften ein Muster zum Rückgängigmachen im Setter implementiert (siehe den herunterladbaren Quellcode). Mithilfe des FieldLookupValue-Objekts im nächsten Codeabschnitt wird im Code der Wert des zugrunde liegenden Id-Werts festgelegt. Die Clientobjektmodell-API nutzt diesen Id-Wert zum ordnungsgemäßen Erstellen der Verknüpfung mit dem zugeordneten Produkt als Nachschlagefeld.

Der letzte erforderliche Schritt zum Umwandeln der ListItem-Objekte in stark typisierte Objekte ist das Erstellen der Logik zum Auffüllen der Eigenschaften. Bei einer größeren Anwendung ist dies eine gute Idee, die einfach umgesetzt werden kann, indem die FieldName-Eigenschaft aus SharePoint in einem benutzerdefinierten Attribut gespeichert wird, das jeder Eigenschaft zugewiesen wird. Da der Schwerpunkt dieses Artikels allerdings auf der Erläuterung der Funktionsweise der API liegt, bietet das folgende Beispiel eine einfachere Version, die die Entität im Konstruktor auffüllt.

public ProductAsset(ListItem source, IEnumerable<Product> products)
{
IsLoading = true;
SourceItem = source;

if (SourceItem != null && SourceItem["FileRef"] != null)
    FileName = SourceItem["FileRef"].ToString();

if (SourceItem != null && SourceItem["File_x0020_Type"] != null)
    FileType = SourceItem["File_x0020_Type"].ToString();

if (SourceItem != null && SourceItem["LegalApprovedDate"] != null)
    LegalApprovedDate = (DateTime)SourceItem["LegalApprovedDate"];

if (SourceItem != null && SourceItem["MarketingApprovedDate"] != null)
    MarketingApprovedDate = (DateTime)SourceItem["MarketingApprovedDate"];

if (SourceItem != null && SourceItem["Product"] != null && products != null)
{
    FieldLookupValue productValue = (FieldLookupValue)SourceItem["Product"];
    AssociatedProduct = products.Where(p => p.Id == productValue.LookupId).FirstOrDefault();
}

IsLoading = false;
}

Der Konstruktor der Klasse arbeitet mit zwei Parametern: dem ListItem-Objekt, dem das Element zugeordnet werden soll, und einer Produktliste vom Typ IEnumerable. Unter Verwendung der Felder jeder Eigenschaft in der ProductAsset-Klasse können Sie die öffentliche Eigenschaft durchlaufen und auf den Wert des ListItem-Objekts festlegen. Um sich die Fähigkeit von Silverlight zu Nutze zu machen, einen ausgewählten Wert direkt an ein Objekt zu binden, wird im Nachschlagevorgang eine LINQ-to-Objects-Abfrage verwendet, um das übereinstimmende Produkt in einer referenzierten Liste auszuwählen. Das Objekt wird mithilfe der LookupId-Eigenschaft ausgewählt, die im FieldLookupValue-Objekt enthalten ist, das im ListItem-Objekt zurückgegeben wird. Bei Überprüfung des Setters für die Product-Eigenschaft in der ProductAsset-Klasse ergibt der Aktualisierungsaufruf für die SourceItem-Eigenschaft möglicherweise nun mehr Sinn. Diese Klasse abstrahiert das zugrunde liegende ListItem-Objekt und aktualisiert die Id-Eigenschaft anhand der Quelle des dazugehörigen Produkts. Dank dieser Abstrahierung muss das ViewModel (Ansichtsmodell) nicht die zugrunde liegenden SharePoint-Objekte aktualisieren, wenn sich die ListItem-Felder ändern. Solange Sie die bidirektionale Bindung verwenden, werden bei Änderungen auf der Benutzeroberfläche die ListItem-Felder automatisch aktualisiert, sodass der Aktualisierungsaufruf an SharePoint erfolgen kann.

Betrachten Sie das Layout der Listen- und Detailansicht in Abbildung 1. Die Oberfläche hat zwei Bereiche: unten die Liste der in einem Raster angezeigten Produktressourcen und oben eine Gruppe bearbeitbarer Formularfelder. Wenn im unteren Raster ein Element ausgewählt wird, werden die Felder oben automatisch so gebunden, dass ein Bearbeitungsformular für das ausgewählte Element bereitgestellt wird.

Das ViewProductAssetsViewModel ist für die Ansicht in Abbildung 1 zuständig. Im XAML-Code wird das ViewModel als StaticResource-Markuperweiterung für das View-Element hinzugefügt. Dadurch werden der Konstruktor aufgerufen und eine ViewModel-Instanz erstellt, an die das View-Element gebunden werden kann. Es folgt der Code mit dem ViewModel-Konstruktor.

<UserControl.Resources>
<ViewModels:ViewProductAssetsViewModel x:Key="ViewProductAssetsViewModelResource"></ViewModels:ViewProductAssetsViewModel>
</UserControl.Resources>

Nachdem eine ViewModel-Instanz erstellt und den Ressourcen des Steuerelements hinzugefügt wurde, wird mit dem folgenden Markup die DataContext-Eigenschaft auf die Instanz der Klasse festgelegt.

<Grid x:Name="LayoutRoot" DataContext="{Binding Source={StaticResource ViewProductAssetsViewModelResource}}">
...

Durch Festlegen der DataContext-Eigenschaft des übergeordneten Objekts auf die Instanz der Klasse, die im Resources-Objekt für das Benutzersteuerelement erstellt wurde, können Abhängigkeitseigenschaften eines Elements im View-Element nun an eine Eigenschaft im ViewModel gebunden werden. Mit dem folgenden Markup wird das Bearbeitungsformular für das ProductAsset-Objekt definiert.

<TextBlock Text="Associated Product"></TextBlock>
<ComboBox ItemsSource="{Binding Path=Products}"
SelectedItem="{Binding SelectedProductAsset.AssociatedProduct, Mode=TwoWay}"></ComboBox>

<TextBlock Text="Marketing Approved Date"></TextBlock>
<sdk:DatePicker SelectedDate="{Binding SelectedProductAsset.MarketingApprovedDate, Mode=TwoWay}"/>

<TextBlock Text="Legal Approved Date"></TextBlock>
<sdk:DatePicker SelectedDate="{Binding SelectedProductAsset.LegalApprovedDate, Mode=TwoWay}" />

<Button Content="Save" Command="{Binding SaveCommand}"></Button>
<Button Content="Cancel" Command="{Binding CancelCommand}"></Button>

Die bearbeitbaren Werte des Steuerelements sind bidirektional an die SelectedProductAsset-Eigenschaft des ViewModel-Elements gebunden, das durch Auswählen eines Elements im DataGrid-Objekt festgelegt wird. Da der Bindungsmodus auf TwoWay festgelegt ist, wird bei Änderung des Werts in den Elementen DatePicker oder ComboBox die Eigenschaft des ausgewählten ProductAsset-Objekts festgelegt. Durch Aufrufen des Setters dieser Eigenschaften werden die zugrunde liegenden ListItem-Felder gemäß dem zuvor in diesem Artikel beschriebenen Muster aktualisiert.

Zum Fertigstellen des Bearbeitungsformulars für Produktressourcen müssen Änderungen mithilfe eines Speicherbefehls an SharePoint zurück übermittelt werden. Nachdem die Felder in der SourceItem-Eigenschaft aktualisiert wurden, muss das SharePoint-Objekt ClientContext aufgerufen werden, um die Änderungen an SharePoint zurück zu übermitteln und für die Bearbeitungen am ListItem-Objekt in der Website ein Commit auszuführen. Der folgende Code enthält die Methode, die an den Befehl für die Schaltfläche Speichern gebunden ist.

private void SaveProductAsset(object param)
{
if (SelectedProductAsset != null)
{
AppViewModel.Instance.OperationIsInProgress = true;
SelectedProductAsset.SourceItem.Update();
AssetsContext.ExecuteQueryAsync(onSaveSucceeded, onSaveFailed);
}
}

private void onSaveSucceeded(object sender, ClientRequestSucceededEventArgs args)
{
AppViewModel.Instance.AppDispatcher.BeginInvoke(
() =>
{
    SelectedProductAsset = null;
    AppViewModel.Instance.OperationIsInProgress = false;
});
}

Wenn die SaveProductAsset-Methode ausgeführt wird, greift die Methode auf die zugrunde liegende SourceItem.Eigenschaft zu, um die UpdateObject-Methode aufzurufen, die vom ursprünglichen ListItem-Objekt verfügbar gemacht wurde, das von der Abfrage für dieses Element von SharePoint zurückgegeben wurde. Für die Update-Methode wird ein Commit ausgeführt, indem der Befehl ExecuteQueryAsync aufgerufen und dann das Bearbeitungsformular zurückgesetzt wird, indem das SelectedProductAsset-Objekt geleert wird.

Bei diesem Beispiel wird für jede Aktualisierung ein einzelner Commit ausgeführt, doch ist dies nicht die einzige Verwendung des ClientContext-Objekts, denn das ClientContext-Objekt unterstützt Batchaufrufe. Dies bedeutet, dass dieses Formular so umgestaltet werden kann, dass alle Aktualisierungen mithilfe eines einzelnen Aufrufs des Speicherbefehls übermittelt werden (siehe das folgende Beispiel).

foreach (ProductAsset item in ProductAssets)
{
   bool operationHasChangesToCommit = false;
   if (item.HasChanges)
   {
      item.SourceItem.Update();
operationHasChangesToCommit = true;
   }
   if(operationHasChangesToCommit)
      AssetsContext.ExecuteQueryAsync(onSaveSucceeded, onSaveFailed);
}

Ryan Morgan ist geschäftsführender Gesellschafter und Seniorarchitekt bei Arrow Consulting & Design in West Palm Beach, Florida. Ryan befasst sich bei Arrow mit der Automatisierung von Geschäftsabläufen sowie mit der Business Intelligence in großem Maßstab für die Bereiche Finanzwesen und Masterdatenverwaltung mithilfe von SharePoint zusammen mit Silverlight und ASP.NET. Ryan ist aktives Mitglied der .NET- und SharePoint-Community und hält Vorträge auf Codecamps, bei SharePoint-Samstagen und bei der DevConnections in Las Vegas. Ryan ist Mitverfasser von Professional DotNetNuke 5 für Wrox. Die Firma von Ryan finden Sie im Internet unter www.ArrowDesigns.com und www.ArrowNuke.com.

Es folgen die technischen Redakteure für Microsoft SharePoint 2010-Artikel von Wrox:

  • Matt Ranlett ist ein SQL Server MVP und war über viele Jahre eine feste Institution der .NET-Entwicklercommunity in Atlanta. Als Gründungsmitglied von Atlanta Dot Net Regular Guys hat Matt mehrere regionale Benutzergruppen gegründet und leitet diese. Nach der Arbeit verbringt er viele Stunden mit lokalen und nationalen Communityaktivitäten, wie beispielsweise der SharePoint 1, 2, 3!-Reihe, der Organisation von drei Codecamps in Atlanta, der Tätigkeit als Vice President of Technology im Vorstand von INETA sowie Auftritten bei mehreren Podcasts wie z. B. .Net Rocks und dem ASP.NET-Podcast. Dennoch fand Matt kürzlich Zeit, sich mit einer wunderbaren Frau namens Kim zu verheiraten, die er bei der Aufzucht von drei riesigen Hunden unterstützt. Matt arbeitet derzeit als Seniorberater für Intellinet und gehört dem Team an, das mithilfe von innovativen Lösungen für den Erfolg von Unternehmen sorgt.

  • Jake Dan Attis. Was Muster, Praxis und Steuerung im Hinblick auf die SharePoint-Entwicklung betrifft, sind Sie bei Jake Dan Attis goldrichtig. Er ist von Moncton, Kanada, in die Region Atlanta gezogen und hat einen Abschluss in angewandter Mathematik, ist aber ein hundertprozentiger SharePoint-Hardcoreentwickler. Normalerweise nimmt Dan an Community-Events in der Region Atlanta teil, hält dort Vorträge oder organisiert derartige Events, wie beispielsweise Codecamps, SharePoint-Samstage und die SharePoint-Benutzergruppe in Atlanta. Wenn Dan einmal nicht in Visual Studio arbeitet, verbringt er gerne Zeit mit seiner Tochter Lily, schaut sich Hockey und Football an und kostet weltweite Biersorten.

  • Kevin Dostalek kann über 15 Jahre Erfahrung in der IT-Branche sowie über 10 Jahre Erfahrung in der Verwaltung großer IT-Projekte und der Führung von IT-Personal aufweisen. Er hat Projekte für Unternehmen ganz unterschiedlicher Größe geleitet und hatte verschiedene Funktionen inne, wie beispielsweise Entwickler, Architekt, Business Analyst, technischer Leiter, Manager Entwicklung, Projektmanager, Programm-Manager und Mentor/Coach. Darüber hinaus hat Kevin zwischen 2005 und 2008 auch als Vice President eine Lösungsbereitstellungsabteilung für einen MS Gold Partner mittlerer Größe geleitet und war später auch als Vice President of Innovation and Education tätig. Anfang 2010 gründete Kevin das Unternehmen Kick Studios, das Beratungs-, Entwicklungs- und Schulungsservices für die Spezialbereiche SharePoint und Social Computing anbietet. Seitdem ist er auch bei zahlreichen Benutzergruppenversammlungen, Treffen und Konferenzen im ganzen Land als Referent aufgetreten. Weitere Informationen zu Kevin finden Sie in seinem Blog "The Kickboard".

  • Larry Riemann verfügt über mehr als 17 Jahre Erfahrung im Entwurf und der Entwicklung von Geschäftsanwendungen für einige der weltweit größten Unternehmen. Larry ist ein unabhängiger Berater, Eigentümer von Indigo Integrations und bietet SharePoint-Beratung ausschließlich über SharePoint911 an. Er ist Autor, veröffentlicht Artikel und hält gelegentlich Vorträge auf Konferenzen. In den letzten Jahren befasste er sich in erster Linie mit SharePoint, dem Entwickeln und Erweitern von über SharePoint hinausgehender Funktionalität. Neben seiner Arbeit an SharePoint ist Larry ein ausgebildeter .NET-Architekt und verfügt über umfangreiches Know-how in Sachen Systemintegration, Unternehmensarchitektur und Hochverfügbarkeitslösungen. Weitere Informationen zu Larry finden Sie in seinem Blog.

  • Sundararajan Narasiman ist ein technischer Architekt bei der Content Management & Portals Group von Cognizant Technology Solutions, Chennai, und verfügt über mehr als 10 Jahre Branchenerfahrung. Sundararajan ist in erster Linie als Architektur- und Technologieberater für die SharePoint Server 2010-Stapel- und Mainstream .NET 3.5-Entwicklung tätig. Er ist ein begeisterter Programmierer und interessiert sich auch für Extremprogrammierung und EDT.

Anzeigen:
© 2016 Microsoft