Jürgen Gutsch : Architektur

Ein Blick auf das Entity Framework 4

Jürgen Gutsch — Tue, 03 Jan 2012 21:18:00 GMT

Angeregt durch ein aktuelles Projekt, musste ich mir das Entity Framework 4 (Microsofts OR-Mapper) anschauen. Bisher hatte ich es vermieden, da ich der Meinung war, dass ich die nötigen Mappings nur über den Designer mit viel Magie und wildem herumgeklicke herstellen kann. Allerdings halte ich es für wichtig, dass die Entities, die ich in meinen Projekten benötige, nicht autogeneriert sind, bzw. nicht vom OR-Mapper generiert werden, da dadurch unnötige Abhängigkeiten zum OR-Mapper entstehen oder unnötige Objekt-Mappings gemacht werden müssen.

Üblicherweise halte ich meine Entities in einem Projekt, das von allen anderen Projekten referenziert wird, die mit diesen Entities arbeiten. Mit NHibernate ist das auch problemlos möglich.

BTW: Ich bin ein großer Fan von NHibernate und nutze diesen OR-Mapper bisher in fast jedem großen Projekt.

Ich möchte also meine Entities wie folgt aufbauen:

public class Customer : EntityBase { [StringLength(150)] [Required] public string Name { get; set; } [StringLength(100)] [Required] public string Street { get; set; } [StringLength(5)] [Required] [RegularExpression("^[0-9]{4,5}$")] public string Postalcode { get; set; } }

EntityBase ist eine Basisklasse, welche die Id bereitstellt, Equals überschreibt, etc. Die hier sichtbaren Attribute stammen von den DataAnnotations und werden zur Validierung genutzt.

Würde ich jetzt das EF wie gewohnt einsetzen, müsste ich z. B. per AutoMapper von den generierten Entities auf meine Mappen. Das möchte ich nicht, bzw. müsste es mit NHibernate auch nicht tun.

DbContext

Nun war es heute René Leupold der mir mit seinem Blog http://databinding.net den entscheidenden Tipp für den DbContext gab. Mit dem DbContext ist es möglich das Entity Framework ähnlich wie NHibernate zu verwenden.

Hilfreich ist auch die Artikelserie “Using DbContext in EF 4.1” im ADO.NET Team Blog

Der DbContext ist ab EF 4.1 verfügbar. Ich selber habe mir für diese Beispiele die EntityFramework.dll 4.2.0.0 per NuGet referenziert.

Das Mapping

Was wir zusätzlich benötigen ist ein Mapping, das hier per Fluent API per C# gesetzt wird:

internal class CustomerMapping : EntityTypeConfiguration<Customer> { public CustomerMapping() { Property(x => x.Name) .HasMaxLength(200) .IsVariableLength() .IsUnicode() .IsOptional(); Property(x => x.Postalcode) .HasMaxLength(30) .IsVariableLength() .IsUnicode() .IsOptional(); } }

Genutzt wird die Konfiguration dann im DbContext:

public class DataContext : DbContext { public IDbSet<Customer> Customers { get; set; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder); modelBuilder.Configurations.Add(new CustomerConfig()); } }

Die Ähnlichkeit mit NHibernate ist an dieser Stelle eindeutig und ich habe meine gewünschte Trennung zwischen den Entities und dem OR-Mapper.

Die Connection

Interessant ist, dass die Verbindung zur Datenbank über den Constructor der Basisklasse DbContext gesetzt werden kann oder aber per Konvention:

<connectionStrings> <add name="DataContext" providerName="System.Data.SqlClient" connectionString="Data Source=[…]" /> </connectionStrings>

Der Name des ConnectionStrings muss einfach so heißen wie der entsprechende DbContext

Benutzen

Wenn die DB schon existiert ist das im Prinzip auch schon alles um mit den Daten zu arbeiten:

[Test] public void SetAndLoadCustomerFromDataBase() { IEnumerable<Customer> customers; using (var context = new DataContext()) { context.Customers.Add(new Customer { Id = Guid.NewGuid(), Name = "Hallo Welt", Street = "Hallo Street 2", Postalcode = "12345" }); context.SaveChanges(); } using (var context = new DataContext()) { customers = context.Customers.Select(c => c).ToList(); } Assert.That(customers.Count(), Is.GreaterThan(0)); }

Das Mapping wird erzeugt, wenn das erste mal der DataContext instanziert wird. Es wird relativ viel mit Lazy<T> gearbeitet, so dass das Debugging der ergebnislisten nicht immer ganz einfach ist.

Demo

Eine Demo werde ich in den nächsten Tagen hier anhängen. Die vorhandenen Projekte muss ich erst noch anonymisieren.

Fazit

Mit dem DbContext scheint das EntityFramework doch noch ein ganz passables Werkzeug und eine ernstzunehmende Alternative zum NHibernate zu sein.

Best Practices: Fehlerbehandlung

Jürgen Gutsch — Thu, 19 Aug 2010 08:42:00 GMT

In der Vergangenheit habe ich in vielen Projekten, vielen Anwendungen und auch hier im Forum immer wieder die gleichen Fehler bei der Fehlerbehandlung gesehen, was mich dazu veranlasst diesen Beitrag hier zu schreiben.

Im Grunde ist es immer folgender Fehler der beim Try&Catch gemacht wird:

try { [do some errors] } Catch (Exception ex) { log.Error(“Meine super duper Fehlermeldung”); throw ex; }

Das ist dann keine Fehlerbehandlung, sondern eher Fehler verstecken!

Oftmals wird dieses Konstrukt (“Fehlerbehandlung” mochte ich es nicht nennen) in jeder Methode genutzt die aufgerufen wird. Das hat dann den Effekt, dass dieses Konstrukt logisch wie folgt verschachtelt wird:

try { try { try { try { [do some errors] } Catch (Exception ex) { log.Error(“Meine erste super duper Fehlermeldung”); throw ex; } } Catch (Exception ex) { log.Error(“Meine zweite super duper Fehlermeldung”); throw ex; } } Catch (Exception ex) { log.Error(“Meine dritte super duper Fehlermeldung”); throw ex; } } Catch (Exception ex) { log.Error(“Meine vierte super duper Fehlermeldung”); throw ex; }

Oftmals wird wenigstens die aktuelle Exception dem Logger übergeben:

Catch (Exception ex) { log.Error(“Meine vierte super duper Fehlermeldung”, ex); throw ex; }

Aber auch das ist nur die halbe Miete.

Was soll da falsch sein ?

Schauen wir uns nochmal das erst Stück Code an. Angenommen es passiert ein Fehler und das Programm, springt in den Catch-Teil. Jetzt geht der Unsinn los:

Es wird eine Unsinnige Fehlermeldung ausgegeben!
Warum?
Falls die Meldung noch relevant sein sollte, enthält sie keine weiteren Informationen zu der eigentlichen Exception. Im Normalfall wurde der Code allerdings im Laufe der projektphase immer wieder geändert, was zur Folge hat, das die Nachricht längst nicht mehr stimmt oder es gibt inzwischen mehrere mögliche Fehlerquellen.
throw ex ist der nächste grobe Fehler: es wird zwar die selbe Exception noch einmal geworfen, mit der selben Fehlermeldung, allerdings wird der immens Wichtige StackTrace abgeschnitten (“breaking the stack”). Der StackTrace beginnt ab der Methode in der throw ex aufgerufen wird. Sollte der Fehler in einer aufgerufenen Komponente auftauchen, kann das nicht mehr ermittelt werden. Es wird immer so aussehen, als wäre der Fehler in der aktuelle Methode aufgetreten, und zwar genau dort, wo thro ex aufgerufen worden ist. Genauso wie der StackTrace geht auch die InnerEception verloren (Danke an Peter für den Hinweis.)
Selbst wenn die Exception an den Logger übergeben wird ist die Fehlerbehandlung unvollständig, denn es wird nur ein unvollständiger StackTrace gelogt.

Im Falle der verschachtelten Try&Catches sieht das so aus, dass 1. keine relevanten Fehlerinformationen geloggt werden und 2. jedes Mal der StackTrace bei jedem Catch von neuem beginnt.

Diese Fehlerbehandlung ist somit keine, sondern eine Selbsttäuschung.

Das wird man spätestens dann merken, wenn man als Entwickler vom Support die Meldung über einen Fehler bekommt und dann das Log-File analysieren muss. Ich wette das viele Fehler nicht per Log-File gefunden werden können.

Was ist zu tun?

Im ersten Schritt sollten alle throw ex Aufrufe durch ein einfaches throw ersetzt werden. Das führt dazu, dass die aufgetretene Exception genau so wie sie ist, nach “oben” weitergeleitet wird. Dann sollte das Logging angepasst werden: Bei einem einfachen Try&Catch sollte das Logging – wenn möglich – so geändert werden, dass die Exception an den Logger übergeben wird (Die meisten Logger sollten das Unterstützen):

try { [do some errors] } Catch (Exception ex) { log.Error(ex); throw; }

Im Fall der Verschachtelten Try&Catches wird nun noch an jeder Stelle in das Log geschrieben. Das ist nicht sinnvoll, das dadurch das Log sehr groß werden kann und die Informationen mehrfach im Log vorhanden sind. Es sollte also nur an einer Stelle geloggt werden und zwar am besten ganz oben, beim letzten Try&Catch.

In ASP.NET kann das sogar in der global.asax bei Application_Error gemacht werden.

Die verschachtelten TryCatches sehen dann logisch wie folgt aus:

try { try { try { try { [do some errors] } Catch (Exception ex) { throw; } } Catch (Exception ex) { throw; } } Catch (Exception ex) { throw; } } Catch (Exception ex) { log.Error(ex); HandleTheException(); }

Im letzten Catch wird dann die eigentliche Fehlerbehandlung gemacht: Es wird dem Benutzer eine sinnvolle Meldung ausgegeben (Nicht die Fehlermeldung, mit der kann der Benutzer nichts anfangen!)

Nach diesem Refactoring, sollte man sich fragen welche Try&Catches dann noch Sinn machen, wen nichts anderes Passiert, als die Exceptions durchzureichen. Ich bin ganz sicher, dass man einige nun Entfernen könnte.

Generell sollte man nicht grundlos alle möglichen Fehler abfangen, sondern in erster Linie Fehler vermeiden. Natürlich gibt es Stellen, bei denen man Fehler nicht Verhindern kann, das ist immer dann der Fall, wenn man aus seiner Anwendung raus auf etwas zugreift: Datenbank und Dateizugriffe, Web- und Webservice-Zugriffe, COM, etc.

Auf diese Art hat man nun schon mal eine relativ saubere Fehlerbehandlung.

Aber es geht immer noch besser:

An Stellen, an denen mögliche Fehler nicht verhindert werden können, können diese abgefangen und mit einer eigenen Exception nach “oben” weitergeben werden. Die ursprüngliche Exception wird dabei als InnerException mitgegeben:

Catch (Exception ex) { throw new MyVeryOwnHttpException(ex) }

So kann man in der Darstellungsschicht individuell auf die Fehler reagieren und dem Benutzer einen entsprechenden Hinweis geben:

Catch (MyVeryOwnHttpException ex) { log.Error(ex.InnerException); HandleTheVeryOwnHttpException(“Die Verbindung zum Server konnte nicht hergestellt werden.\n Bitte prüfen Sie ob Sie mit dem Internet Verbunden sind.\nUnd so weiter und so fort”, ex); }

Man kann so spezielle Arten von Ausnahmen zusammenfassen und entsprechend drauf reagieren. Es ist dem Anwender in der Regel egal, was der genaue Fehler ist. Ob das jetzt ein Verbindungsfehler ist oder der Server einen Fehler zurückgibt ist egal. Wichtig ist, dass in diesem Fall die Anwendung nicht mit dem Server kommunizieren kann.

In der Log-File steht auf jeden Fall der konkrete Fehler mit dem kompletten StackTrace und die Fehlersuche wird dadurch wesentlich vereinfacht.

Event Based Components

Jürgen Gutsch — Wed, 18 Aug 2010 20:22:00 GMT

In den vergangen Monaten habe ich einiges theoretisches über Event Based Components (kurz EBCs) gelesen. Das meiste von Ralf Westphal, in seinem Blog oder aus seiner Feder in der dotnetpro. Auch Golo Roden schrieb in seinem Blog über das Thema.

Verwirrung

Angespornt durch die Beiträge habe ich in den letzten Wochen selber versucht EBCs zu schreiben und zu entwickeln und bin zuerst gescheitert. Sobald ich die ersten Komponenten geschrieben und “zusammengesteckt” hatte, verlor ich relativ schnell den Überblick über die Komponenten und deren Verbindungen.

Woran lag das?

Golo wies mich auf die fehlerhafte Benennung der Events in Ralf Westphals Beispielen hin, die entgegen dem .NET Framework mit dem Präfix “On” begannen.

Ich habe also von vorne begonnen und die Events wie im .NET-Framework üblich benannt.

Beispiel:

public event Action<Customer> EntitySaving (wird vor dem Speichern ausgelöst)
public event Action<Customer> EntitySaved (wird nach den Speichern ausgelöst)

Und siehe da: die Verwirrung war beseitigt :-)

Vorteile

Die Vorteile der EBCs sind klar und wurden in den oben genannten Beiträgen auch oft genug angesprochen. Die zwei größten Vorteile sind – aus meiner Sicht – zum einen die isolierte Testbarkeit der Komponenten und die flexible Möglichkeit die Komponenten zusammenzuführen.

Refactoring

In den letzten Wochen habe ich also meinen angehenden Lizenz-Manager, einem großen Refactoring unterzogen und auf EBCs umgebaut. Ich habe allerdings vorerst meine Service-Klassen nicht komplett auseinandergerissen. Also nicht fürs Speichern, Löschen und Lesen separate Komponenten gebaut (das wäre dann der nächste schritt), sondern es bei jeweils einer Komponente mit standardmäßig drei Input- und drei Output-Pins belassen. Ich habe lediglich die generische Validierung komplett entkoppelt und dafür eine weitere Komponente angelegt, die vor jedem Speichern “eingesteckt” werden kann.

Die vorhandenen Unit-Tests musste ich leicht anpassen. Die Tests für die Servies, die hauptsächlich die Validierung getestet haben konnte ich entfernen und in die Test für die Validator-Komponente aufnehmen. Die Tests sind alle kleiner geworden, da Abhängigkeiten gar nicht mehr berücksichtigt werden müssen, wenn sie nicht zusammengesteckt worden sind. Beispiel: Die Service-Methode zum Speichern, muss keine Validierung mehr testen. Und die Tests der Validierung ist unabhängig vom Speichervorgang.

[TestFixture] [Category("GO.LicenceManager.Services.ModelValidator")] public class Wenn_ein_Kunde_validiert_wird { [Test] public void darf_der_Vorname_nicht_fehlen() { Customer customer = new Customer { [….] }; IModelValidator<Customer> modelValidator = new ModelValidator<Customer>(); Assert.Throws<PropertyNotSetException<Customer>>( () => modelValidator.Validate(customer), "'Name' must not be null or empty"); } } public class ModelValidator<T> : IModelValidator<T> where T : IEntity { public void Validate(T model) { Type type = typeof(T); IEnumerable<PropertyInfo> propertyInfos = type .GetProperties(BindingFlags.Public | BindingFlags.Instance); [….] } } public class CustomerService : ICustomerService { private readonly ICustomerRepository _customerRepository; public CustomerService(ICustomerRepository customerRepository) { _customerRepository = customerRepository; } public void Save(Customer customer) { OnEntitySaving(customer); if(customer.Id==Guid.Empty) { customer.Id = Guid.NewGuid(); } _customerRepository.Save(customer); } public event Action<Customer> EntitySaving; public void OnEntitySaving(Customer entity) { var entitySaving = EntitySaving; if (entitySaving != null) { entitySaving(entity); } } [….] }

Zusammenstecken:

Customer customer = new Customer { [….] }; IModelValidator<Customer> validator = new ModelValidator<Customer>(); ICustomerService customerService = new CustomerService(customerRepository); customerService.EntitySaving += validator.Validate; // <== zusammenstecken customerService.Save(customer);

Die Tests hätten wir damit vereinfacht, die Komponenten müssen sich nicht mehr kennen und sind komplett entkoppelt. Die Komponenten müssen aber irgendwie und irgendwo zusammengeführt werden, um zu funktionieren.

Die Komponenten müssen “zusammensteckt” werden.

Dabei ist entweder Handarbeit und eine gute Dokumentation gefordert, oder man versucht das zu automatisieren. Ralf Westphal hat dafür einen EBC-Binder geschrieben, der allerdings nur funktioniert, wenn gewisse Konventionen eingehalten werden: Unter anderem müssen die Events eben mit dem Präfix “On” beginnen…

Ich werde hierfür wahrscheinlich eine Art Binding-Datei anlegen die im XML-Format nicht nur das Binding selber regelt, sondern dieses auch dokumentiert. Mal sehen, was sich so machen lässt :-)

Vorerst werde ich im Lizenz-Manager allerdings noch die Repositories und die verschiedenen Views implementieren müssen. Bis zur See# Party werde ich wohl aber nicht mehr dazu kommen…

Dependency Inection mit LightCore im dot.NET Magazin

Jürgen Gutsch — Wed, 05 May 2010 09:51:00 GMT

Ganz stolz kann ich heute mal folgendes schreiben:

Mit dem Artikel “Keine Sorge, es piekst nur ganz kurz – Dependency Injection mit LightCore” ist mein erster Artikel in einer deutschsprachigen Fachzeitschrift erschienen.

Zu finden ist der Artikel in der Ausgabe 6.2010 des dot.NET Magazins, welche die meisten Abonnenten bereits in der Hand halten sollten.

In diesem Artikel beschreibe ich kurz das Dependency Injection Pattern und vor allem die einfache Umsetzung des Patterns mit Peter Buchers Dependency Injection Container LightCore.

Übrigens gibt es LightCore auch auf FaceBook und Twitter:
FaceBook Seite: http://www.facebook.com/pages/LightCore/
Twitter: http://twitter.com/lightcore

Katastrophenfall ‘NULL’?

Jürgen Gutsch — Mon, 03 May 2010 11:29:00 GMT

Mit seinem Beitrag Kleiner Helper für Linq to Sql: ToListOrDefault() hat Thomas Bandt am Wochenende eine Diskussion zum Thema “Null als Rückgabewert” angestoßen (man beachte die Kommentare). Wie nicht anders zu erwarten (:-P), wurde die Diskussion natürlich auch von Ralf Westphal aufgenommen: Null oder nicht Null, das ist hier die Frage (auch hier die Kommentare beachten).

Weiter ging es wieder Bei Thomas Bandt mit dem Beitrag Null Verständnis der es tatsächlich auf 40 Kommentare gebracht hat. Auch Ilker Cetinkaya konnte es sich diesmal nicht verkneifen ebenfalls etwas zu dem Thema zu schreiben: Null Toleranz, vorauf hin Ralf schlagfertig reagierte: Es hilft nichts, dass es darauf ankommt – nicht nur beim Null-Problemo [OOP 2010] und Ilkers Haltung kritisierte. [Update] Ilkers Antwort folgte gestern relativ schnell: Kein Yin ohne Yang, kein Null ohne Pointer (Auch hier bitte unbedingt die Kommentare lesen)

Ein scheinbar vorläufiges Fazit zur Diskussion schreibt Thomas in seinem letzten Beitrag zum Thema Null: Null Erkenntnis? Ganz im Gegenteil.

[UPDATE]
Eben hat sich auch der Karsten zum Thema geäußert: #Handwerk: Clean vs. pragmatisch?

Was hier fast wie ein Sportbericht aussieht, ist ein Diskussion über ‘Null’ als Rückgabewert und über eine fehlende Regel zu dem Thema ob und wann ‘Null’ als Rückgabe erlaubt ist, oder nicht.

Verschiedenste Lösungen kommen in allen Beiträgen und deren Kommentaren vor. So unter anderem:

Exception statt ‘Null’
Leere Objekte statt ‘Null’
‘Null’ nur passend zur Kategorie
‘Null’ nur mit Vorsicht
it depends
‘Null’ im Katastrophenfall

Katastrophenfall ‘NULL’

Und dieser letzte Punkt ist eigentlich der einzige, an dem ich mich wirklich anstoße:

Ilker Cetinkaya [http://www.gmbsg.com/null-toleranz/]
Ich gebe in einigen Methoden NULL zurück. Meistens genau dann, wenn ich wirklich damit ausdrücken möchte, dass etwas katastrophales passiert ist.

Wenn etwas eine Katastrophe ist, sollte diese Katastrophe nur in wirklich unvermeidbaren Ausnahmen auftreten. In diesem Fall kann auch eine Ausnahme erzeugt werden. Ich bin in so einem Fall tatsächlich für eine Exception, statt einer ‘Null’ (Punkt 1).

Als Webentwickler dagegen bin ich der Ansicht das man die Erzeugung von Exceptions unbedingt mit Vorsicht genießen sollte und nur dann einsetzen sollte, wenn es wirklich unvermeidbar ist. Den Exception Handling kostet Performance. Exceptions sollten also auch Exceptions bleiben und “exceptionally used” werden. Im Web ist es IMHO wichtiger Fehler zu vermeiden, als für jeden möglichen Fall eine neue Exception zu erzeugen. Zum Thema “Fehler vermeiden” gehört IMHO auch, das Auslösen von Exceptions vermeiden, wenn es sich irgendwie vermeiden lässt. Aus diesem Grund sollte der erste Punkt “Exceptions statt ‘Null’” ebenfalls mit Vorsicht genossen werden.

Und was ‘Null’ als Rückgabewert angeht, enthalte ich mich fürs erste (was spezielle Regeln angeht) und bleibe Beobachter dieser Grundlagendiskussion. Ich bin mir einfach selber noch nicht schlüssig, was hier richtig und was falsch ist. Die Rückgabe von ’Null’ ist bequem, harmlos und tastbar, kann also nicht grundlegend falsch sein.

Im Moment tendiere ich noch zu dem Punkt “it depends” ;-)

BASTA! Tag 4: Intensions & Interfaces – Making Patterns Concrete

Jürgen Gutsch — Thu, 25 Feb 2010 08:22:18 GMT

Udi Dahan (udidahan.com) beginnt in dieser Session mit der Beschreibung wie Software immer komplexer und komplexer werden kann und das es das Ziel sein sollte Software flexibel zu machen und flexibel zu halten.

Oh man, es ist zu früh um einem englischsprachigen Sprecher, bei einem Thema über Design Patterns zu folgen und dabei mit zu schreiben… ;-) Daher an dieser Stelle erst mal keine weiteren Infos. Ich werde am Wochenende diese sehr, sehr interessante Session in eigene Worte fassen und an dieser Stelle posten. Ich bitte das zu Entschuldigen… :-(

LINQ und LINQ to SQL

Jürgen Gutsch — Wed, 30 Dec 2009 21:28:00 GMT

Neulich erhielt ich eine E-Mail mit einigen Fragen zur Verwendung von “LINQ to SQL” in n-Tier-Applikationen, die ich hier anonymisiert beantworten möchte:

Wie sieht Microsoft beim Einsatz von “LINQ to SQL” die Machbarkeit von n-Tier-Applikationen, die über eine separate Datenzugriffsschicht verfügen?

Da ich nicht Microsoft bin und auch kein offizielles Statement von Microsoft zu dieser Problematik kenne, kann ich diese Frage so nicht beantworten. Ich kann nur sagen, dass es Beispiel-Applikationen von Microsoft gibt, in denen durchaus “LINQ to SQL” innerhalb der Datenzugriffsschicht eingesetzt wird.

Wenn ich das richtig sehe, krankt “LINQ to SQL” bei seiner Nutzung mit .NET daran, dass ich bei der Nutzung aller automatisch generierten Objekte auf allen Ebenen der Anwendung einen Verweis auf “LINQ to SQL” benötige, oder?

Wenn man die automatisch generierten Objekte in der ganzen Applikation nutzen möchte, ist das sicher so. Aufgrund von der Austauschbarkeit der Datenzugriffsschicht würde ich allerdings empfehlen diese automatisch generierten Objekte nicht über alle Schichten hinweg zu verwenden, sondern “LINQ to SQL” komplett in der Datenzugriffsschicht zu kapseln.

Oder ich führe eine (aufwändig zu implementierende) Mapping-Schicht ein, in der ich die “LINQ to SQL”-generierten Datenklassen in anwendungsinterne Objekte übersetze.

Das wäre eine Möglichkeit, aber aus meiner Sicht nicht empfehlenswert. Ich würde bei einer klassischen 3-Schicht-Architektur eine vierte ~~parallele~~ vertikale Schicht einbinden, welche die Datenobjekte enthält die über alle Schichten hinweg zur Verfügung stehen sollen.

Die Datenzugriffsschicht ist dann verantwortlich für das bereitstellen der Daten und das Mappen der Daten in die Datenobjekte der vierten ~~parallelen~~ vertikalen Schicht.

Für den Fall, dass mal per “LINQ to XML” auf eine XML-Datenbasis zugegriffen werden soll, muss so nur die Datenzugriffsschicht ausgetauscht werden.

Auch wenn ich Benutzeroberfläche (Grids, etc.) an “LINQ to SQL”-Results binden möchte, habe ich das Problem, dass ich damit ja die Datenlogik in die GUI ziehe, und damit die eigentlich unterste mit der eigentlich obersten Schicht verbinde...?

Auch das ist ein Grund für die oben beschriebene ~~parallele~~ vertikale Anwendungsschicht. “LINQ to SQL” ist auf diese Art komplett von den anderen Schichten entkoppelt und die Datenzugriffsschicht liefert nur die gewünschten Objekte.