Automatisch generierte DAL in einer ASP.NET-Anwendung

Question

Gibt es eine Möglichkeit, anhand einer gespeicherten Prozedur automatisch eine Datenzugriffsschicht zu generieren? Ich verstehe, dass dies mit Codesmith durch die Erstellung von cs-Vorlagen getan werden kann, aber ich frage mich, ob es eine kostenlose/bezahlte Lösung gibt.

Der Plan sieht vor, dass die Architektur eine solche haben soll:

ASP.NET-Code dahinter -> Geschäftsschicht -> Datenzugriffsschicht -> Gespeicherte Prozedur.

Die BL-Ebene dient als Durchgang zur DAL und kann auch automatisch generiert werden.

Für Tipps/Ratschläge bin ich sehr dankbar!

Answer 1

Verwenden Sie einfach Entity Framework:
http://msdn.microsoft.com/en-us/library/bb399203.aspx

Answer 2

Ich schlage noch nicht vor, dass Sie Entity Framework verwenden, da es noch viele Macken hat. Wenn .NET 4.0 offiziell veröffentlicht wird, werden Sie Entity Framework 4.0 haben. Mit diesem Release werde ich wahrscheinlich NHibernate und LINQ to SQL aufgeben (beide haben sehr unterschiedliche Rollen) und nur noch EF verwenden, da es sowohl die Benutzerfreundlichkeit von LINQ to SQL als auch die Flexibilität von NH bietet.

Für den Moment schlage ich vor, dass Sie LINQ to SQL verwenden, da es sehr einfach ist, es zum Laufen zu bringen und die meiste Zeit funktioniert es einfach!

Answer 3

Entity Framework in seiner jetzigen Form ist für gespeicherte Prozeduren ein No-Go. Es gibt einfach zu viel manuelle Arbeit, die getan werden muss, um jede gespeicherte Prozedur zum Laufen zu bringen. Ich kann nicht für .net 4 Entity Framework sprechen, obwohl.

LINQ to SQL ist sehr Stored-Proc-freundlich. Führen Sie SQLMETAL mit der Option /procs aus, um Ihre DAL automatisch generieren zu lassen.

Allerdings gibt es zwei Einschränkungen:

1. LINQ to SQL führt keine Stored Procs aus, die dynamisches SQL verwenden.
2. LINQ to SQL führt auch keine gespeicherten Prozeduren aus, die Daten aus temporären Tabellen zurückgeben.

Der offensichtliche erste Grund ist, dass LINQ to SQL die notwendigen Metadaten für diese Sprocs nicht generieren kann, aber dynamisches SQL in Stored Procs ist ohnehin eine schlechte Praxis.

Answer 4

Linq2SQL oder SubSonic eignen sich beide gut für diesen Zweck.

Bearbeiten: Linq2Sql ist angeblich "tot", aber es ist immer noch recht nützlich in seiner aktuellen Form. Ich würde nur keine langfristigen Investitionen in sie machen.

Answer 5

Eine weitere Stimme für Entity Framework, obwohl dies von der zugrundeliegenden Tabellenstruktur abhängt, nicht von einer gespeicherten Prozedur. Mir ist keine Möglichkeit bekannt, wie Entity Framework die Klassenstruktur anhand der Ausgabe einer gespeicherten Prozedur bestimmen kann.

Ich habe festgestellt, dass unser bester Ansatz darin besteht, unsere Klassen und CRUD-Stored Procedures manuell zu programmieren. Viele werden mit dieser Lösung nicht einverstanden sein, aber meiner Erfahrung nach führt die Verwendung von ORM-Frameworks zu suboptimalem SQL, das begrenzt ist, vor allem wenn man bedenkt, wie leistungsfähig Stored Procedures sind, die das Framework blockiert.

Klischees gibt es nicht ohne Grund: Wenn Sie es richtig machen wollen, machen Sie es selbst. Je mehr Komponenten von Drittanbietern Sie in Ihre Anwendung integrieren, desto mehr Probleme müssen Sie lösen, die nicht unter Ihrer direkten Kontrolle stehen. Ich hasse es, dem Not-Invented-Here-Syndrom anzuhängen, aber dies ist ein Fall, in dem es meiner Meinung nach zutrifft.