Best Practices: 3-Tier-Architektur in LINQ

Question

Ich arbeite an einem persönlichen Projekt (C # / ASP.NET), die LINQ to SQL verwenden. Die Lösung wird (bisher) ein Webformular Projekt, ein Namespace-Projekt (Business-Logik) und ein Test-Projekt. Ich bin in den sehr frühen Stadien so weit (deutlich in der Entwurfsphase).

Gibt es ein Paradigma für die 3-Tier Architektur hier? Es scheint, wie die DAL völlig nutzlos in diesem Fall ist; fühlt sich an wie ich von der Geschäftslogik, die LINQ-Abfrage direkt durchführen sollte.

Es kommt auch zu mir, wenn ich eine nur resident halten und Datacontext, dass etwa passieren, ich nur die eine offene Verbindung benötigen würde. Dies hätte den zusätzlichen Vorteil der Änderungen auf einmal statt granular zu begehen. Irgendwelche Gedanken auf, dass?

Ich fand dieses Themas , aber es scheint ein unvollständiges Bild zu malen. Gibt es in ausführlichen Artikel zu diesem Thema?

Answer 1

können Sie denken an LINQ-to-SQL als DAL, so dass es mit „direkt von der Business-Logik“ ist nicht unbedingt eine schlechte Sache.

http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx hat einige populäre L2S Ansätze aufgelistet .

Auf unserem Projekt wollten wir nicht um den Datenkontext passieren, so dass wir ein ähnliches Muster wie # 3 aus dem obigen Link verwendet (Ambient Datacontext, siehe unten). Es hatte einige Probleme, aber es funktionierte recht gut; zumindest für unser Webprojekt.

  

Ambient Datacontext (Derzeit wird diese verwendet wird)

     

Die Idee hinter Umgebungsdatacontext ist, dass Kontext für einen bestimmten Thread oder ein Httpcontext (in asp.net) erstellt wird, sobald ein erster Aufruf für die Datacontext ist. Dann wird der gleiche Kontext für diesen Thread verwendet oder fordert, wenn es von Hand angeordnet ist. Dies wird durch Speichern des Kontextes, in dem Anfrage / Thread-Datenspeicher erfolgt. Der Ansatz für dieses Muster ist ähnlich statische Datacontext jedoch Trennung wird für jeden Thread und Anfragen zur Verfügung gestellt. Das funktioniert wirklich gut in Asp.Net jedoch wieder durch einige der Probleme der statischen Kontext geplagt wird.

     

Probleme mit diesem Muster:

* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
* Portability across thread is very hard
* Unit of work pattern is not transparent enough

Answer 2

Sie könnten ein bisschen auf Domain Driven Design nachlesen.

Mit der Praxis der Domain Driven Design (DDD), Sie haben eine reiche ‚Domain-Modell‘, in dem Sie das Problem Domäne ausdrücken, die Sie angehen wollen. Dieses Domain-Modell besteht aus Klassen (und structs), mit denen Sie Ihre Geschäftseinheiten modellieren. Das Domänenmodell consits auch von Endlagern.
Ein Repository ist eine Art von Abstraktion, die Sie in Ihrem Domain-Modell verwenden (und in der Anwendung); Das Repository ist eine Abstraktion des Datenspeichers. Durch das Repository können Sie Entitäten abrufen und Sie die Repository-Einheiten bestehen bleiben können.

In Ihrem Fall Ihre Repositorys könnten Linq verwenden intern auf SQL auf die Datenbank zu sprechen. Beachten Sie jedoch, dass Ihr Repository nicht verantwortlich sein sollte verwalten (Öffnen / Schließen) die Verbindung und die Transaktion (Start / Commit / Rollback) though. Warum ? -> weil das Repository hat keine Kenntnis oder Vorstellung von dem Kontext, in dem sie verwendet wird. Es ist Ihre Anwendung oder einen Dienst Schicht (die Schicht, die Ihr Domain-Modell verwendet und damit das Repository), die zum Öffnen eine neue Verbindung und Start / begehen Transaktionen verantwortlich sein sollte. (Oder in Ihrem Fall, öffnen Sie ein neues Datacontext). Sie könnten dann die Datacontext in das Repository übergeben.

(Eric Evans hat ein großes Buch DDD in Bezug auf, wenn auch eine harte Nuss zu knacken, von Zeit zu Zeit).

Answer 3

Sie sollten mit Ihrer Terminologie vorsichtig sein. Wenn Sie LINQ sagen, meinen Sie Linq to SQL und wenn Sie 3-Tier sagen, die in der Regel bedeutet, dass Sie sprechen von einem Bereitstellungsszenario mit drei getrennten Maschinen. Ich bin mir nicht sicher, ob das ist, was Sie meinen.

Eine dreischichtige Architektur ist immer noch eine gute Idee, wenn ein ORM-Tool wie Linq-to-SQL. Die DAL wird nur ein Ort, um Ihre Abfragelogik zu speichern. Es ist eine gute Idee, um Ihre Anfragen aus Ihrer Business-Schicht zu nehmen, weil Abfragen eine Persistenz Sorge, keine Geschäftslogik Bedeutung sind.

Die übliche Technik, um den Datenkontext für die Verwaltung ist eine einzige Datenkontext pro Anfrage haben.

Im Hinblick auf den anderen Artikeln zu diesem Thema können Sie jede Architektur Anleitung für jedes ORM-Tool aussehen können - Linq-to-SQL ist es nicht anders. Suchen Sie nach Artikeln über Architektur für NHibernate.

Answer 4

Die LINQ to SQL-Bibliothek ist Ihre DAL in diesem Fall, und statt der traditionellen API Anrufe von Ihrem Business-Schicht zu machen (zB DAL.GetObjectById (id)) haben Sie die Flexibilität von viel ausdrucks Anfragen in die DAL.

Wenn Sie einige anderen Bedürfnisse haben, zum Beispiel Ihrer eigenen LINQ-Anbieter, die zu einem nicht-MSSQL Datenträger verbinden, dann würden Sie Ihre eigenen DAL implementieren.

Zusätzlich die Datacontext in Bezug auf, ist es nicht einen Singletonmuster mit „einem resident Datacontext“ zu verwenden, empfohlen. Ein Datacontext-Objekt sollte eine einzelne logische Transaktion darstellen, was auch immer die für Ihre Anwendung bedeutet. (Paraphrasiert von http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspx )