Beim nächsten Treffen der .Net Developer-Group Ulm dürfen wir diesesmal Dariusz Parys begrüßen, der zum Thema “Architektur der Datenanbindungsschicht, insbesondere ADO.NET Data Services und Entity Framework” spricht. Der Abstract verspricht schon mal einen sehr spannenden Abend:

LINQ to SQL, ADO.NET, Entity Framework, Entity Data Model, REST mit ADO.NET Data Services oder Serialisierung mit WCF ? – neben einem Überblick über die Alternativen und detailliertere Darstellung des Entity Frameworks wird darauf eingegangen, welche Kriterien beim O/R-Mapping zur Bewertung zur Verfügung stehen und diskutiert, welcher Nutzen darin liegt, die Datenanbindung von einer technischen Ebene auf eine logische zu heben.

Ích glaube das dürfte ein Themengebiet sein mit dem im Moment jeder Entwickler in irgendeiner Weise käpft und so dürfte sich Dariusz schon mal auf eine ganze Reihe von Fragen einstellen (Mir selbst fallen da schon eine ganze Reihe ein).

Wer also Interesse an dem Thema hat, ist herzlich eingeladen am Dienstag 17.02.2008 um 18:00 zu uns zu kommen.

Weitere Infos unter:

http://www.dotnet-ulm.de

Auf dieser Seite sind jede Menge Beispiele zum Thema LINQ thematisch geordnet aufgelistet. Hier findet man wirklich für viele Einsatzgebiete entsprechende Beispiele. Wirklich empfehlenswert! 

101 LINQ Samples

Möchte man den kleinesten Key aus einem Dictionary abfragen, dann kann man das jetzt mit Hilfe von LINQ ganz einfach tun. Das Dictionary-Objekt ist in C#3.0 mit einer ensprechenden Extension versehen wordurch das Ganze so einfach ist, wie man sich das immer gewünscht hat.

Dictionary<int, double>
ListObject = new Dictionary<int,double>
{ {2004, 1.5}, {2005, 2.7}, {2006, 3.8} }; int minYear
= ListObject.Min(l => l.Key); 

Vor kurzem hatte ich in einem Post beschrieben, wie man mit C#3.0 Listen effizient initialisieren kann. Das Ganze funktioniert übrigens auch mit Dictionaries. Das siehtr dann einfach so aus:

productVersion.Sales = new Dictionary<int,double>
{ {2004, 1.5}, {2005, 2.7}, {2006, 3.8} };

Objekte und Listen lassen sich jetzt in C# 3.0 sehr schön initialisieren. War bisher um ein relativ einfaches Objekt zu initialisieren sehr viel Code erforderlich, hat sich das nun deutlich verkürzt:

Bisher:

List<cProduct> Products = new List<cProduct>();
cProduct Product = new cProduct(); Product.ID
= 1; Product.BusinessDevelopmentComment = "";
Product.MarketingComments = ""; Product.VersionDescriptions
= new List<cProductVersionDescription>();
Product.INNs = new List<cProductINNItem>();
cProductVersionDescription VersionDescription = new cProductVersionDescription();
VersionDescription.ID = 1; VersionDescription.LastPCMDate = DateTime.Now; VersionDescription.LastPCMDecision
= "Go"; VersionDescription.NPV = 689.54; VersionDescription.ProductID
= 1; VersionDescription.ProductVersionID = 1; VersionDescription.VersionName = "Version1";
Product.VersionDescriptions.Add(VersionDescription); cProductINNItem INN = new cProductINNItem();
INN.INN = 8; INN.Dosage = 1.5; INN.DosageUnit = 1; INN.Volume = 1; INN.Comment = "Test-Comment";
INN.INNOrder = 1; Product.INNs.Add(INN); INN = new cProductINNItem();
INN.INN = 2; INN.Dosage = 2.5; INN.DosageUnit = 2; INN.Volume = 2; INN.Comment = "Test-Comment2";
INN.INNOrder = 2; Product.INNs.Add(INN);

Neu mit C#3.0:

List<cProduct> Products = new List<cProduct>
{ new cProduct{ ID = 1, BusinessDevelopmentComment
= "", MarketingComments = "",
VersionDescriptions = new List<cProductVersionDescription>
{ new cProductVersionDescription{ ID=1, LastPCMDate=DateTime.Now,
LastPCMDecision="Go", NPV=689.54, ProductID=1,
ProductVersionID=1, VersionName="Version1"} },
INNs = new List<cProductINNItem> { new cProductINNItem{
INN=8, Dosage=1.5, DosageUnit=1, Volume=1, Comment="Test-Comment",
INNOrder=1}, new cProductINNItem{ INN=2, Dosage=2.5,
DosageUnit=2, Volume=2, Comment="Test-Comment2",
INNOrder=2} } } };

Bisher konnte man den Code noch etwas vereinfachen, indem man einen entsprechenden Konstruktor für die Objekte erstellt hat, in dem die Initialisierungswerte übergeben werden konnten. Hier bietet die neue Version aber den Vorteil, dass diese leichter zu leesen ist, da die Parameter hier entsprechend bezeichnet sind. Beim Konstruktor musste immer Intellisense zu Hilfe genommen werden um herauszufinden, um welchen Parameter es sich handelt.

Ich habe in einer Anwendung ein Objekt, das über ca. 30 List<double> Properties verfügt. Dieses Objekt möchte ich nun mit LINQ to SQL in die Datenbank schreiben. Natürlich unterstützt LINQ 1:n-Beziehungen in Objekten aber in der Datenbank müsste ich dann für jedes List-Property eine eigene Tabelle anlegen und für jedes Property einen eigenen Typ definieren. Das schien mir doch sehr umständlich.

Ich habe dann nach einer Möglichkeit gesucht, die List-Elemente etwas effizieter zu speichern, am einfachsten in einem Feld je Liste, da ich die für die Abfrage eh nicht brauche. Aber wie kann ich die Ausgabe von LINQ in die Datenbank steuern? Wie kann ich erreichen, dass LINQ meine Daten entsprechend formatiert?

Googeln brachte keine vernünftigen Ergebnisse und sonst bin ich auch nicht fündig geworden, aber dann kam die Idee (manchmal ist es schneller erst nachzudenken bevor man googelt, aber das vergisst man oft ;-)). Die Grundidee war, für jede Liste noch ein zusätzliches Property anlegen, das die Daten im Getter und Setter entsprechend formatiert. Die Hoffnung war, wenn ich dieses Property mit einem Column-Attribut versehe, wird LINQ den formatierten Inhalt schreiben und beim Lesen wieder zurückformatieren.

            public List<string>
Sales { get; set; } [Column(Name="Sales", DbType
= "nvarchar(4000)")] privatestring SalesString
{ get { returnstring.Join("|",
Sales.ToArray()); } set { if (value != null)
Sales = value.Split('|').ToList();
} }

Ich habe einfach eine Text-Spalte in der Datenbank verwendet und die einzelnen List-Elemente mit einem Trennzeichen verbunden (der Einfachkeit halber habe ich mit einer List of Strings gearbeitet. Für die Tests ist das ausreichend und sollte auf beliebige andere Typen übertragbar sein).

Einen kleinen Stolperstein gibt es noch. Beim Ausführen erhielt ich folgende Meldung:

LINQ verwendet Optimistic Locking für das Schreiben und hat wohl Probleme, wenn der Inhalt des Property im Getter verändert wird. Abhilfe schafft hier das zusätzliche Attribut UpdateCheck, also sollte das Attribut zu dem Property so aussehen:

[Column(Name="Sales",
DbType = "nvarchar(4000)", UpdateCheck=UpdateCheck.Never)]

Hier sind natürlich auch noch andere Möglichkeiten der Datenrepräsentation möglich. Hier mal ein Beispiel mit XML-Serialisierung und diesesmal auch mit Doubl-Werten.

            public List<double>
Sales { get; set; } [Column(Name="Sales", DbType
= "xml", UpdateCheck=UpdateCheck.Never)] privatestring SalesString
{ get { UTF8Encoding encoding = new UTF8Encoding();
MemoryStream ms = new MemoryStream(); XmlSerializer
xmlSer = new XmlSerializer(typeof(List<double>));
xmlSer.Serialize(ms, Sales); return encoding.GetString(ms.ToArray());
} set { if (value != null)
{ UTF8Encoding encoding = new UTF8Encoding();
MemoryStream ms = new MemoryStream(encoding.GetBytes(value));
XmlSerializer xmlSer = new XmlSerializer(typeof(List<double>));
Sales = (List<double>)xmlSer.Deserialize(ms);
} } }

Dank an Bernhard Gojer für den Lösungsansatz.

Scott Gutherie hat in seinem Blog eine interessante Artikel-Serie zu LINQ to SQL

Data Access Improvements with LINQ to SQL

LINQ to SQL is a built-in OR/M (object relational mapper) in .NET 3.5.  It enables you to model relational databases using a .NET object model.  You can then query the database using LINQ, as well as update/insert/delete data from it.  LINQ to SQL fully supports transactions, views, and stored procedures.  It also provides an easy way to integrate business logic and validation rules into your data model.  Below are some of the articles I've written that explore how to use it:

• Part 1: Introduction to LINQ to SQL
• Part 2: Defining our Data Model Classes
• Part 3: Querying our Database
• Part 4: Updating our Database
• Part 5: Binding UI using the ASP:LinqDataSource Control

I'll be adding several more articles to my series above in the weeks ahead.  I think you'll find that LINQ to SQL makes it dramatically easier to build much cleaner data models, and write much cleaner data code.