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
Das patterns & practices Team hat einen Application Architect Guide veröffentlicht. Das 365 Seiten umfassende Dokument kann kostenlos von CodePlex heruntergeladen werden und beschreibt Architekturansätze für Windows, Web, Mobile und andere Anwendungen. Neben theoretischen Grundlagen werden auch explizite Guidelines für verschiedene Design-Aspekte einer Anwendung beschrieben. Absolut empfehlenswert! patterns & practices: Application Architecture Guide 2.0 (The Book) - Home
Standardmäßig stellt Visual Studio die Prozessor-.Architektur für Anwendungen auf "Any CPU". Vor allem mit Bibliotheken gibt es damit allerdings öfters Probleme auf x64 Systemen, wenn die Bibliotheken unter 64Bit Betriebssystemen nicht sauber laufen. Eine Möglichkeit ist, die Anwendung explizit für x86 zu kompilieren, dann wird diese auch auf x64 Systemen im 32Bit Modus ausgeführt (siehe auch den Blogeintrag zur TFS-API unter x64). 
Allerdings muss man hier mit ClickOnce ein wenig vorsichtig sein. Wenn man eine Anwendung zunächst mit "Any CPU" über ClickOnce verteilt hat und anschließend auf x86 umstellt, dann meldet ClickOnce „The deployment identity does not match the subscription” bzw.
„Die Bereitstellungsidentität stimmt nicht mit dem Abonnement überein.“ Verschiedene Einträge im Internet verweisen zunächst darauf, dass das Zertifikat das Problem sein könnte. Da wir in der Zwischenzeit bei uns eine Domänen-Umstellung hatte, war diese Erklärung zunächst auch sehr plausibel. Dann stellte sich allerdings heraus, dass dieses Problem durch die Prozessor-Architektur verursacht wird. ClickOnce verwendet diese wohl als sog. "subscription identity" und behauptet einfach, dass es sich dabei um eine andere Anwendung handelt. Um das Problem zu umgehen sollte man also bereits beim ersten Demployment sehr gut überlegen, ob man die Anwendung nicht unter dem x86-Modus kompiliert.
Über das PropertyGrid-Control habe ich ja mehrmals gebloggt (z.B. hier). Dieses Control verwendie ich recht häufig um z.B. den Inhalt eigene Konfigurations-Klassen zu editieren. Zusammen mit der XML-Serialisierung lassen sich so sehr flexible Konfigurationsmöglichkeiten schaffen. Nun hatte ich die Anforderung eine dynamische Datenstruktur an ein PropertyGrid zu binden. Da stand ich zunächst vor einem Problem. Bisher habe ich nur Objekte mit Properties unterschiedlicher Typen an das PropertyGrid gebunden. Nun habe ich eine Liste von Objekten, die die Elemente im PropertyGrid beschreiben. Wie aber diese an das PropertyGrid binden? Das schöne ist, das das PropertyGrid sich hier als sehr flexibel erweist. Man muss folgende Schritte durchführen: - Man brauch eine Klasse für ein einzelnes Property
- Dann brauchen wir eine Collection für diese Properties. Diese leiten wir von CollectionBase und ICustomTypeDescriptor ab und implementieren die Interfaces. Entscheidend ist hier die Methode GetProperties. Hier werden nun ine PropertyDescriptionCollection aus unseren Properties aufgebaut. Diese Methode ruft das PropertyGrid auf um sich dieProperties zu besorgen, die es rendern soll. Hier können wir nun also von einer belibigen Datenstruktur die benötigten
Informationen für das PropertyGrid aufbauen.
- Dafür brauch wir jetzt noch einen cCustomPropertyDescriptor. Diesen leiten wir von PropertyDescriptor ab und implementieren es.
- Nun können wir unsere Properties aufbauen und an das PropertyGrid binden. Ich habe das CustomPropertyGrid als eigenes Control angelegt. Der Code ist nun sehr simpel:
1: private void Form1_Load(object sender, EventArgs e) 2: { 3: cPropertyCollection props = new cPropertyCollection(); 4: props.Add(new cPropertyItem("BoolValue", "This is a boolean value", false, true, "Properties")); 5: props.Add(new cPropertyItem("StringValue", "This is a string value", false, "Test123", "Properties")); 6: props.Add(new cPropertyItem("Folder", "Path for folder", false, "", "Path")); 7: 8: this.artisoPropertyGrid1.SelectedObject = props; 9: }
Damit erhält man folgendes Ergebnis. Man sieht die dynamisch angelegten Properties mit ihrem Name, in die Kategorien untergliedert und mit der Beschreibung. Das PropertyGrid wählt automatisch die gewohnten Controls abhängig vom Datentyp aus.
Dis ist schon ganz nett. Ich möchte aber für das Folder-Property einen entsprechenden Editor angeben können. Bei statischen Klassen vrwendet man einfach Attribute, aber bei dynamischen? Dazu wird die verfügbare Dokumentation sehr, sehr dünn. Hierzu haben wir auf der Property-Klasse eine Attribute-Arary. Diese Attribute können wir nun in der GetProperties-Klasse an den cCostomPropertyDescriptor übergeben. Der Aufbau der Properties sieht dann so aus:
1: private void Form1_Load(object sender, EventArgs e) 2: { 3: cPropertyCollection props = new cPropertyCollection(); 4: props.Add(new cPropertyItem("BoolValue", "This is a boolean value", false, true, "Properties")); 5: props.Add(new cPropertyItem("StringValue", "This is a string value", false, "Test123", "Properties")); 6: props.Add(new cPropertyItem("Folder", "Path for folder", false, "", "Path", 7: new TypeConverterAttribute(), 8: new EditorAttribute(typeof(System.Windows.Forms.Design.FolderNameEditor), typeof(System.Drawing.Design.UITypeEditor)))); 9: 10: this.artisoPropertyGrid1.SelectedObject = props; 11: }
Nun kann man im Feld für den Wert für das Property "Folder" auf einen Button klicken und erhält einen Dialog zur Auswahl eines Verzeichnisses.
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.
Scott Mitchell hat 75 Tutorials zum Thema Data Access mit ASP.Net 2.0 geschrieben. Hier ist praktisch alles an Technologie beschrieben, was für die Programmierung von datenbankbasierten Webanwendungen mit ASP.Net 2.0 notwendig ist. Einzig LINQ wird momentan noch ausgespart. Eine wirklich tolle Sammlung an guten Informationen.
Data Access Tutorials : The Official Microsoft ASP.NET 2.0 Site
Hat man ein typisiertes DataSet und arbeitet darin mit mehreren TableAdaptern, dann stellt sich die Frage, wie Updates auf diesen TableAdaptern in eine Transaktion zusammengefasst werden können. Das Problem dabei ist, dass jeder TableAdapter seine eigene Connection nutzt. Es gibt grundsätzlich zwei Lösungsansätze:
- Man verwendet den TransactionScope aus dem System.Transactions-Namespace. Diese Vorgehensweise hat allerdings den Nachteil, dass die verschiedenen Connections nur über eine Distributed Transactions verwaltet werden können. Das ist nicht unbedingt das Nonplusultra was die Performance angeht und eigentlich ja auch mit Kanonen auf Spatzen geschossen, da typischerweise alle TableAdapter ja auf die gleiche Datenbank gehen dürften und damit die Ditributed Transactions etwas überkandidelt sind.
- Man verwendet eine Connection für alle TableAdpater. Hierzu gibt es glücklicherweise die Möglichkiet, dass man die Connection der Tableadapter austauschen kann. Man kann z.B. einfach die Connection des ersten TableAdapters allen anderen zuweisen und dann auf dieser Connection mit BeginTransaction eine neue Transaktion beginnen und diese dann mit Commit bzw. RollBack abschließen. Alternativ kann man natürlich auch manuell eine Connection erzeugen und diese dann allen TableAdaptern zuweisen.
Eine sehr schöne Beschreibung dieser Lösungsansätze hat John Waters unter folgendem Link veröffentlicht: ADO.NET : Getting TableAdapters to participate in transactions
Bei der Dotnet Usergroup Bremen wurde das Thema in einem kleinen Artikel ausführlich diskutiert. Link to DOTnet Usergroup Bremen Danke an Chris für den Link
Ich habe im Speicher ein DataView mit ca. 22000 Datensätzen. Aus diesem DataView musste ich nun innerhalb einer Schleife 55 Abfragen machen. Dazu zwei Methoden:
dvINNs.RowFilter = "ProductDSID = " + drProducts["ProductDSID"];
foreach (DataRowView drINN in dvINNs)
{
...
}
oder
foreach (DataRow drINN in dvINNs.Table.Select("ProductDSID = " + drProducts["ProductDSID"]))
{
...
}
Ich habe eine Zeitmessung durchgeführt. Dies ergab für Methode I 1,5 Sek und für Methode II 0,03 Sek. D.h. der Select ist um Faktor 50 (in meinem Beispiel) schneller als der RowFilter.
Oft möchte man den Monatsnamen eines Datums in der jeweiligen Landessprache des Anwenders ausgeben. Dies kann man einfach mit einer Zeile Code bewerkstelligen:
string MonthName = Application .CurrentCulture.DateTimeFormat.MonthNames[DateTimeValue.Month-1];
Alternativ kann man auch die Kurzform der Monate über die Eigenschaft AbbreviatedMonthNames abfragen.
Will man eine spezifische Sprache zur Ausgabe verwenden, kann man dies natürlich auch tun indem man einfach das entsprechende CultureInfo-Objekt verwendet:
CultureInfo ci = new CultureInfo("de-DE");
ci.DateTimeFormat.MonthNames[MonthID];
MSDN Solve ist die Lösung für alle Entwickler, die praxis-orientierte Hilfestellungen bei typischen Programmier-Herausforderungen suchen. MSDN Solve liefert verständliche Antworten auf immer wiederkehrende Fragen aus dem IT-Alltag und sorgt dafür, dass Sie Stolperfallen in Software-Projekten künftig leicht umschiffen.
http://www.microsoft.com/germany/msdn/solve/default.mspx
Die aktuelle Bildschirmauflösung abzufragen ist in .NET denkbar einfach, möchte man jedoch alle verfügbaren Auflösungen erfragen und eventuell sogar eine neue Auflösung setzen, muss man auf die Win32 API-Mittel zurückgreifen. Dieser Beitrag stellt eine Klasse zur Verfügung mit der mit jeweils einer Zeile Code über die verfügbaren Auflösungen iteriert werden bzw. eine neue Auflösung festgelegt werden kann
http://www.codegod.de/WebAppCodeGod/Main.aspx?pid=168
Ein wenig bekanntes Control ist das FlowLayoutPanel, das in VS 2005 standardmäßig enthalten ist. Mit diesem Control kann man Unterelemente in einer fließenden Ansicht darstellen wie das z.B. auch von Web-Seiten bekannt ist. Sie möchten eine Liste von Textboxen die untereinander stehen? Kein Problem mit dem FlowLayoutPanel. Sie können eine beliebige Richtung wählen (von rechts nach links, von oben nach unten etc.). Passen nicht alle Control in die Reihe, wird automatisch ein Umgruch eingefügt. Damit ist das FlowLayoutPanel wesentlich flexibler als man diese Funktion z.B. mit Docking erreichen könnte. Vor allem bei dynamisch generierten Control leistet das FlowLayoutPanel gute Dienste!
Oft möchte man Daten, die aus Excel in die Zwischenablage kopiert wurden, in der Anwendung verarbeiten. Dies geht recht einfach, da die Excel-Daten in der Zwischenablage einfach als CSV-Format vorliegen.
string ExcelValue = "";
IDataObject ClipboadData = Clipboard.GetDataObject();
if (ClipboadData.GetDataPresent(DataFormats.CommaSeparatedValue))
{
StreamReader ExcelReader = new StreamReader((Stream)ClipboadData.GetData(DataFormats.CommaSeparatedValue));
while (!ExcelReader.EndOfStream)
{
ExcelValue = ExcelReader.ReadLine();
}
}
Man holt sich die Daten aus der Zwischenablage und prüft diese, ob sie im CSV-Format vorliegen. Dann kann man mit Hilfe eines StreamReaders die Daten lesen. Die Daten kommen dann in einem Format wie z.B. 5,8;8,9;7,5. Das lässt sich nun problemlos in der eigenen Anwendung verarbeiten.
Um von generischen Objekten den Typ abzufragen kann man folgenden Code verwenden:
Dictionary<string, int> MyObject = new Dictionary<string, int>();
Type T = MyObject.GetType();
Type[] Ts = T.GetGenericArguments();
Dieser Code liefert ein Array zurück, das im ersten Element System.String und im zweiten System.Double enthält.
Weitere Infos unter http://msdn2.microsoft.com/en-us/library/b8ytshk6.aspx
Unter IDesign gibt es einen Download, mit dem das My-Objekt von VB auch unter C# genutzt werden kann.
http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=-1&tabid=19&download=141
The My class in VB often simplifies and streamlines many operations, from Network programming to clipboard, to audio access, and so on. What takes sometimes a programming fit in C# can be done in one line using the My class in VB. If VB has Me and My, then C# should have this and That. The That class is the C# equivalent of the VB My class. It is a static class that uses the VB implementation as much as possible, and it requires adding a referencing to Microsoft.VisualBasic. The That class is instrumental when working in heterogeneous environments and when dealing with in porting of VB to C# or visa-versa.
Weitere interessante Downloads gibt's unter http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11#ES
Bisher war es recht mühsahm, Oberflächen für verschiedene Sprachen zu erstellen. Mit VS 2005 ist das jetzt ein Kinderspiel. Einfach auf der Form die Eigenschaft Localizable auf true setzen. Dann die Oberfläche für die Standard-Sprache aufbauen. Anschließend die Eigenschaft Language auf der Form auf eine explizite Sprache einstellen und Anpassungen vornehmen (Lables, Buttons etc. neu beschriften). VS legt für die Zweitsprache automatisch eine .resx-Datei an, in der diese sprachspezifischen Einstellungen gespeichert werden.
Während des editierens kann man beliebig zwischen den Sprachen umschalten und die Oberfläche für die jeweilige Einstellung editieren. Genial ist dabei, dass nicht nur Texte in den sprachspezifischen Ressource-Dateien gespeichert werden, sondern auch alle anderen Einstellungen. Wird ein Button z.B. in Englisch mit "Save" betittelt, kann es sein, dass die deutsche Bezeichnung "Speichern" zu lang ist und der Platz nicht ausreicht. Kein Problem. Den Button einfach in der deutschen Einstellung vergrößern und schon wird auch die Größe des Buttons in Abhängigkeit der Sprache gewählt.
Dass viele Operationen mit einem string recht langsam ist, ist ja weitgehend bekannt, auch dass man hier besser einen StringBuilder verwendet. Folgendes Beispiel ist unter Performance-Aspekten sehr ungünstig:
string Text = "";
for (int i=0; i<100000; i++)
{
Text += "x";
}
Was weniger bekant ist, die Erklärung dafür. Wird einem String ein neuer Wert zugeweisen, so wird das Objekt jedes mal neu angelegt. In dem obigen Beispiel wird also 100000 mal ein neues String-Objekt angelegt und das alte verworfen. Das kostet natürlich Zeit. Dahingegen ist der StringBuilder dynamisch erweiterbar. Nach der initialisierung wird er mit einer Kapazität von 16 Zeichen angelegt. Die Kapazität verdoppelt sich nun jedesmal, wenn die Kapazität überschritten wird. Mit dem einfügen des 17. Zeichens wird die Kapazität also auf 32 erhöht etc. Beim Stringbuilder kann man im Konstruktor auch schon eine größere Kapazität angeben.
In der AssemblyInfo.vb bzw. AssemblyInfo.cs gibt es zwei Einträge zur steuerung der Versionierung.
<Assembly: AssemblyVersion( "0.9.*")>
<Assembly: AssemblyFileVersion("0.9.2.0")>
Das Problem dabei ist, dass die AssemblyVersion durch * automatisch nummeriert werden kann, dass das aber bei der AssemblyFileVersion nicht funktioniert. Möchte man, dass beide gleich sind, muss man lediglich die AssemblyFileVersion löschen.
Mit Hilfe der Eigenschaft UpdateBatchSize kann eingestellt werden, wieviele Update-Befehle beim Updaten eines Datasets in die Datenbank zusammengefasst werden sollen.
DataAdapter and Batch Updates. In the previous version of ADO.NET, when updating a database with changes from a DataSet, the Update method of a DataAdapter performs updates to the database one row at a time.
As the method iterates through the rows in the specified DataTable, it examines each DataRow to see if the row has been modified. If the row has been modified, the method calls the appropriate UpdateCommand, InsertCommand or DeleteCommand, depending on the value of the RowState property for that row. Every row update involves a network round-trip to the database.
In ADO.NET 2.0, the DataAdapter exposes an UpdateBatchSize property. Setting the property to a positive integer value causes updates to the database to be sent as batches of the specified size. For example, setting the UpdateBatchSize to 10 will group 10 separate statements and submit them as a single batch. Setting the UpdateBatchSize to 0 will cause the DataAdapter to use the largest batch size that the server can handle. Setting it to 1 disables batch updates as rows are sent one at a time.
Event Behavior Changes with Batch Updates. The DataAdapter class has two update-related events i.e. RowUpdating and RowUpdated. In previous versions of ADO.NET, and when batch processing is disabled, each of these events is generated once for each row processed. RowUpdating is generated before the update occurs, and RowUpdated is generated after the database update is completed.
When batch processing is enabled, multiple rows are updated in a single database operation. Therefore, only one RowUpdated event occurs for each batch, whereas the RowUpdating event occurs for each row processed.
When batch processing is disabled, the two events are fired with one-to-one interleaving where one RowUpdating event and one RowUpdated event fire for a row, then one RowUpdating and one RowUpdated event fire for the next row, until all of the rows are processed.
|
Copyright © 2010 Thomas. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|