Linq to SQL und logische Partitionierung (DAL, BLL)

Question

Wir werden eine unserer Websites in .Net neu aufbauen. Ich habe viele Artikel gelesen und mag die Idee, unser Projekt in eine Datenzugriffsschicht (DAL), eine Business-Logik-Schicht (BLL) und eine Präsentationsebene zu unterteilen (wir kommen aus dem klassischen ASP, das ist ein großer Schritt für uns)). Ich mag auch Linq zu SQL.

Da Linq zu SQL auf schnelle Entwicklung zielt, ist es wirklich möglich mit Linq zu SQL eine DAL-, BLL- und Präsentationsebene zu haben? Mit Linq zu SQL würde die DAL die Entitäten oder den Linq-Code zurückgeben, der möglicherweise in der BLL geändert werden könnte? Die Beziehung zwischen der DAL und BLL mit Linq zu SQL scheint ein unscharfes Thema ohne Konsens zu sein - und da dies für uns ein großer Sprung ist, möchte ich auf jeden Fall einen guten Spielplan haben, bevor ich in irgendetwas eintauche.

Typisierte Datasets scheinen dafür besser gerüstet zu sein, aber wenn ich mit Linq etwas Ähnliches erreichen kann, würde ich diesen Weg gehen.

Ich würde gerne von nHibernate und anderen 3rd-Party-Bibliotheken bleiben.

Answer 1

Wir bauen genau das auf, was Sie beschrieben haben, und wir verwenden L2S dafür. Einverstanden, dass die Beziehung zwischen der DAL und BLL ein wenig unscharf ist, aber wir haben eine eindeutige BLL und eine eindeutige DAL. Alle unsere Logik ist in der BLL und alle Datenabfrage/Änderung erfolgt über Aufrufe an die DAL (mit LINQ-Aufrufe).

Unsere App verwendet keine typisierten Datasets. Wir haben Entity-Klassen erstellt, um unsere Objekte darzustellen. Jetzt, wo ich ein paar Monate damit verbracht habe, einen Teil davon zu bauen, sehe ich nicht, dass wir jemals wieder zu den Datensätzen zurückkehren.

Auch würde ich nicht auf L2S hängen, die "auf die schnelle Entwicklung ausgerichtet ist". Das klingt wie ein Prototyping-Tool. Wir finden, dass es ein Werkzeug der industriellen Stärke ist. Dies könnte im Gegensatz zu dem stehen, was Microsoft jetzt dazu sagen könnte, da sie lieber EF benutzen würden.

Randy

Answer 2

Ich empfehle einen Schritt zurück zu nehmen und wieder auf Ihre Anforderungen aussehen.

Benötigen Sie echte 3 Ebenen (das ist physische Bereitstellung auf verschiedenen Maschinen) oder nur logische Partitionierung Ihrer Anwendung?

Ich machte genau diesen Fehler auf der ersten großen Anwendung, die ich geschrieben habe. Ich brauchte nie physische 3 Ebenen (und werde nie brauchen), aber die Anwendung so konzipiert. Die auffälligste Konsequenz war, dass I Linq2Sql keine getrennte Change Tracking auf den Entitäten unterstützt. Ich habe Linq2Sql Entity Base verwendet, um diese Einschränkung zu umgehen, aber es verletzt das Konzept der Persistenz Ignoranz sehr schlecht (man weiß danach immer besser, oder?).

Going real n-Tiers hat eine Menge anderer Auswirkungen auf die Anwendungsarchitektur.

Sie benötigen Nachrichtenübergabe, Datentransferobjekte usw. Linq2SQL ist ein anständiges ORM, die enge Integration mit LINQ bietet einzigartige Möglichkeiten. Andere ORMs brauchen noch etwas Zeit, um hier aufzuholen. NHibernate 3.0 ist hier ein Licht am Ende des Tunnels. Linq2SQL ist ein großartiges ORM, wenn Sie einfache Datenmodelle haben und in einer "Klasse pro Tabelle" -Methode abbilden können.

Für die getrennte Änderungsverfolgung (die Sie benötigen, wenn n-Tiers gehen) haben andere ORMs bessere Unterstützung.

Und endlich:

(wir vom klassischen ASP kommen sind so diese ist ein massiver Schritt für uns)

Unter diesen Umständen ich besonders vorsichtig sein würde. Switching-Technologien werden oft unterschätzt. Selbst die intelligentesten Programmierer in Ihrem Team treffen falsche Entscheidungen, weil sie keine Erfahrung mit der Technologie haben. Trotzdem ist es wichtig, neue Wege zu gehen und Ihre Fähigkeiten zu verbessern. Diejenigen, die niemals versagen, werden niemals Erfolg haben.

Answer 3

IMHO, LINQ to SQL ist derzeit die beste verfügbare Wahl. Es macht wirklich das Arbeiten mit Daten schmerzlos und macht fast Spaß. :-) Wenn Sie an LINQ to SQL interessiert sind, würde ich uns unser PLINQO Projekt ansehen. LINQ to SQL bietet einige großartige Verbesserungen, um es zu einer besseren Gesamtlösung zu machen.

Answer 4

Ich würde sagen L2S ist der DAL. Die L2S + Geschäftslogik in separaten Klassen wird zu einer zusammengeführten DAL + BLL, wobei die DAL-Seite die L2S-Laufzeit und der L2S-generierte Code (Datenkontext, Entitätsklassen usw.) ist.

Sie können sie immer noch leicht trennen, so dass der L2S-generierte Teil und alle Erweiterungen zu den Entitäten und dem Datenkontext in einer separaten DLL und zusätzlicher Geschäftslogik in einer separaten DLL/Dienst/etc. In vielen Fällen besteht jedoch keine Notwendigkeit, sie zu trennen.

Ein Grund für die Trennung in DAL + BLL bei Verwendung von L2S wäre, wenn Sie voraussehen, dass Sie auf eine andere Datenzugriffstechnologie umsteigen oder wenn Sie mehr als eine Datenzugriffstechnologie verwenden. Eine separate DAL mit beliebigen L2S-spezifischen Komponenten zu haben, sollte das Ausschalten der DAL erleichtern. Wenn Sie DAL + BLL aus diesem Grund trennen möchten, sollte die L2S DAL-DLL die Entity-Klassen, abgeleitete Klassen oder Projektionsklassen und Methoden zum Abrufen von Entitäten oder Auflistungen (List usw.) verfügbar machen, den DataContext jedoch intern im DAL beibehalten Klasse zu vermeiden, dass L2S-spezifische Dinge (L2S-Abfragen usw.) in die BLL rinnen.

JMHO.

---

Da andere L2S Werkzeuge erwähnt, ist hier eine vollständigere Zusammenfassung dessen, was draußen ist es: http://www.thinqlinq.com/post.aspx/title/linq-tools

Answer 5

ich mit Linq denke, die DAL und BLL Konzepte sind nicht mehr sinnvoll. So habe ich linq Klassen und einige Getter & Setter unter dem Ordner "Domain" unter dem Code (übergeordnet) Ordner platziert. Dann habe ich "Repository" -Klassen und "FontEnd" -Klassen erstellt.