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

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:

1. 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.
   
2. 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

Enthält auch das Entity Framework. Damit soll OR-Mapping in ADO.Net integriert werden.

http://blogs.msdn.com/adonet/archive/2006/08/15/701479.aspx

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.