Sollten Business-Logik-Objekte Kenntnisse über ihre LINQ-zu-SQL-Datenobjekte besitzen?

Question

Ich habe mir einige ähnliche Fragen angesehen, aber ich habe keine gesehen, die sich direkt auf mich übertragen, also vergib mir, wenn es ein Duplikat ist.

Für die Trennung von Bedenken versuche ich meine Geschäftsobjekte mit Logik zu den LINQ to SQL-Datenobjekte in der .dbml-Datei (ziemlich neu zu diesem BTW) zuordnen. Es sieht jedoch so aus, dass meine Geschäftsobjekte über die entsprechenden LINQ2SQL-Objekte Bescheid wissen müssen. Ich habe gelesen this article über den Versuch, POCOs mit Hilfe einer XML-Mapping-Datei zu verwenden, und es scheint, als ob das ähnlich ist, was ich will, mit der Ausnahme, dass ich eine Eins-zu-eins-Zuordnung von Tabellen zu Klassen wegen einer viel- zu viele Beziehungen, für die ich eine extra Tabelle erstellen musste.

Ich kann den Datenzugriff in meiner Geschäftslogik so gut einkapseln, dass Code, der meine Geschäftsobjekte verwendet, nichts über die Datenbank wissen muss, was gut ist, aber die Business-Schicht ist immer noch eng mit den Daten verbunden Zugriffsschicht, so dass ich die DAL nicht austauschen konnte, ohne meine Geschäftsschichtobjekte zu ändern oder neue (die dieselben Schnittstellen implementieren) für verschiedene Datenanbieter zu erstellen.

Wie kann ich diese Schichten entkoppeln?

Answer 1

Nicht sicher, ob Sie irgendwie an LINQ to SQL gebunden sind, aber das, was Sie erreichen möchten, ist so ziemlich der Standardwert in NHibernate. Ich empfehle, sich NHibernate anzusehen, um zu sehen, ob es einfacher wäre, zwischen LINQ to SQL zu wechseln.

Ich habe festgestellt, dass das Kämpfen eines Werkzeugs fast immer eine schlechte Idee ist.