LINQ to SQL in 3-Schicht-Architektur

Question

Ich verwende derzeit die 3-Layer-Architektur (DAL, BLL, Presentation Layer).

Ich frage mich, wie ich die 3-Schichten-Architektur mit LINQ to SQL implementieren kann. Ich weiß nicht, ob LINQ in DAL oder BLL sein sollte. LiNQ scheint die Fusion von DAL und BLL zu sein.

Implementiert jemand LINQ in 3-Schicht-Architektur vor?

Answer 1

Ich benutze Linq-to-SQL/XML und ich betrachte meine Anwendung als 3-Tier. Der Unterschied zwischen einer Pre-Linq-Anwendung ist, dass jetzt die Datenzugriffsebene viel kleiner und leichter ist, was eigentlich eine sehr gute Sache ist!

In meinem alten DAL würde ich wie gehabt Methoden:

public virtual int CountCustomersInCountry(string country) { 
    // Plug in raw SQL. 
} 

public virtual List<Customer> GetCustomersInCountry(string country) { 
    // Plug in raw SQL. 
} 

public virtual int CountCustomersForDepartment(string department) { 
    // Plug in raw SQL. 
} 

public virtual List<Customer> GetCustomersForDepartment(string department) { 
    // Plug in raw SQL. 
} 

etc. etc. ad-infinitum 

Ich habe jetzt die folgende Art von Methoden:

public virtual int Count(Expression<Func<T, bool>> where) { 
    // Plug in Linq-to-SQL DataContext here.   
} 

public virtual T Get(Expression<Func<T, bool>> where) { 
    // Plug in Linq-to-SQL DataContext here. 
} 

public virtual List<T> Get(Expression<Func<T, bool>> where, string orderByField, int offset, int count) { 
    // Plug in Linq-to-SQL DataContext here. 
} 

die neuen DAL Methoden aufrufen und mit ein wenig Hilfe von DynamicLinq ich benutze:

int countryCount = Count(c => c.Country == country); 
List<Customer> customers = Get(c => c.Country == country, "inserted", 0, 25); 
int departmentCount = Count(c => c.Department == department); 
List<Customer> customers = Get(c => c.Department == department, "inserted", 0, 25); 

und alles, das, bevor Sie fahren Sie auf Hinzufügen, Aktualisieren und Löschen wh Ich werde Single Lines mit Linq2SQL! Meine DAL besteht nun aus 10 Methoden, bei denen es wie bisher einfach war, für jedes Objekt, für das sich meine DAL kümmerte, 20 bis 30 Methoden zu bekommen! Ich würde sehr empfehlen, versuchen Sie es zu verstehen, da es wirklich viel Code sparen wird.

Answer 2

Ich denke, es hängt davon ab, wie Sie mit LINQ aussehen. In einem normalen Plan denke ich, dass es wirklich in der DAL sitzt, da es der zugrunde liegenden Datenstruktur eng folgt. Sie können dann im BLL darüber abstrahieren.

Answer 3

Die Objekte, die LiNQ erstellt, werden typischerweise als Business-Layer-Objekte bezeichnet, obwohl sie eine höhere Kopplung mit der Datenschicht erfordern, als dies normalerweise ratsam ist. Wenn Sie jedoch Strukturen auf höherer Ebene als die in LiNQ direkt dargestellten Strukturen haben, können zusätzliche Controller diese dann als Business-Layer verwenden, wobei LiNQ mehr und mehr zu einem Data Layer wird.

Es hängt wirklich vom Umfang der in der Datenbank dargestellten Objekte ab, sowie von der Höhe der Kopplung, die Sie erreichen möchten. Da LiNQ Nachfragen in den Vordergrund stellt, kann es eine Anwendung übermäßig durchdringen.

Answer 4

LINQ ist nicht für 3-Tier-Architektur geeignet. Es eignet sich am besten für 2-Tier-Architektur.

Ich persönlich machte mein Diplom-Projekt in 3 Tier und entschied, LINQ zu verwenden, aber später fiel ich diese Idee wegen vieler Probleme. Das große Problem ist "Optimistic Concurrency Control"

Weil LINQs Entity Objekte in verbundenen Umgebung von DataContext funktioniert. also während der Update- und Löschlogik. es gibt Fehler.

Answer 5

Bei LINQ-to-SQL geht es hauptsächlich um die DAL - es handelt sich um eine Datenzugriffstechnologie. In einer einfachen App hält Sie jedoch nichts davon ab, Ihre von LINQ erstellten Objekte an die Business-Schicht zu übergeben und sie sogar an Ihre Benutzeroberfläche zu binden. Warum nicht?

Sie müssen sich jedoch bewusst sein, dass Sie sich in diesem Fall relativ stark an LINQ-to-SQL binden. Wenn das für dein Szenario in Ordnung ist - großartig, benutze es! Es ist eine Designentscheidung, die Sie selbst treffen müssen, je nach den Bedürfnissen Ihres Projekts.

Wenn das System komplexer wird, insbesondere wenn Ihre aus den Datenbanktabellen erstellten LINQ-Objekte nicht 1: 1 mit Ihren Geschäftsobjekten übereinstimmen, können Sie die Business-Schicht verwenden, um reale Geschäftsobjekte aus Ihrem LINQ zu "assemblieren" Objekte. Mit Hilfe eines Tools wie AutoMapper können Sie sogar viel links-rechts-zuweisen "Affe" -Code schreiben :-)

Auf der anderen Seite, wenn Sie in einer solchen Situation sind, könnten Sie Außerdem sollten Sie sich ADO.NET Entity Framework und nicht LINQ-to-SQL ansehen. EF bietet Ihnen viele dieser erweiterten Funktionen, die für eine kleine App wahrscheinlich zu viel Aufwand darstellen, aber für eine Unternehmens-App möglicherweise von entscheidender Bedeutung sind. Dinge wie die Unterstützung mehrerer Datenbankanbieter, Dinge wie die Zuordnung Ihrer Geschäftsobjekte zu einer anderen physischen Darstellung in Ihrer Datenbank und so weiter.

Marc

Answer 6

ich hinzufügen, die Einheiten in einem DAL-Projekt und erstellen Sie ein Repository für den Zugriff ich brauche. Wenn Sie Linq für SQL-Objekte in der BLL wirklich nicht wollen, müssen Sie die Double-Mapping-Technik verwenden. Die Verwendung des Repository-Musters macht es leicht, die DAL zu verfälschen.

Answer 7

Ich schrieb ein einfaches Telefonbuch mit Linq und 3-Schicht, können Sie es herunterladen, und wenn Sie Fragen dazu haben, füllen Sie frei, um mich zu fragen.

Es ist erhältlich bei: http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=7597&lngWId=10