SQL to LINQ

05/03/2009 - 18:53 von Gerold Mittelstädt | Report spam
Hallo,

ich habe einen Wizard, in dem sowohl neue Datensàtze für die DB (SQL
Server 2005) erstellt als auch bereits vorhandene bearbeitet werden
können. Jeder Datensatz wird durch eine Klasse repràsentiert, die über
LINQ zur DB gemappt ist und darüberhinaus noch diverse weitere
Eigenschaften und Methoden bereitstellt.

Doch wie setz ich das INSERT/UPDATE jetzt am Besten um?

Ohne LINQ wàre der Ablauf folgender:

- Seite wird aufgerufen
- Klasse, die die Werte bereitstellt wird neu erstellt bzw. mit ID
aufgerufen und holt sich die Daten aus der DB (normales SELECT innerhalb
New(int))
- Werte aus Klasse werden den Steuerelementen im Wizard zugewiesen
- Klasse wird im ViewState abgelegt.
- Benutzer füllt Felder im Wizard aus oder àndert sie
- Klasse wird aus ViewState geholt und bekommt neue/geànderte Werte
zugewiesen
- Klasse enhàlt Save-Methode, die SQL INSERT oder UPDATE ausführt, je
nachdem ob eine ID vorhanden ist oder nicht.

Doch wie verhàlt es sich jetzt, wenn LINQ im Spiel ist?
Gibt es innerhalb der Klasse die Möglichkeit sich selbst zu füllen bzw.
mit der DB zu synchronisieren?

Oder sitz ich gerade einfach nur gewaltig auf der Leitung und hab ein
dickes Designproblem?

Viele Grüße!
 

Lesen sie die antworten

#1 Thomas Bandt
05/03/2009 - 21:41 | Warnen spam
Gerold Mittelstàdt schrieb:
Oder sitz ich gerade einfach nur gewaltig auf der Leitung und hab ein
dickes Designproblem?



Hm :-)

Also ich habe seit Jahren meine Sachen in (min.) 3
Schichten getrennt, z.T. nicht ganz sauber, aber
immerhin:

.aspx.cs macht das ganze DataBinding und ggf. noch
Eingabevalidierung usw.

-> Reicht Daten an und bekommt Daten vom Business-
Layer

-> der sie wiederum vom Data Layer bekommt und an
diesen weitergibt

Inzwischen heißt das bei mir Service und Repository,
aber das spielt keine Rolle.

Für mich ist LINQ to SQL eine nette Geschichte die
ich gerne einsetze, allerdings ist es eben nur ein
OR-Mapper für den SQL-Server - d.h. ich würde einen
Teufel tun und die LINQ-to-SQL-Klassen noch mit
Geschàftslogik beladen oder die Objekte gar als
Geschàftsobjekte verwenden.

Auf diesen Trichter kann man aber leicht kommen, wenn
man sich die anfànglichen Tutorials, gerade bei ScottGu,
anschaut und befolgt.

Was hab ich gemacht? Einfach SqlCommand und SqlDataReader
weggeschmissen und durch LINQ to SQL ersetzt - aber nur
im Data Layer.

Machst du das auch so àndert sich für dich an deiner
bisherigen Vorgehensweise also überhaupt nichts.

Der Vorteil: so bleibt eine saubere Trennung erhalten,
und wenn dem Kunden einfàllt dass ihm demnàchst die
6000-EUR-SQL-Server-Lizenz zu teuer ist, wechselst du
einfach auf MySQL. Mit oder ohne LINQ - das kann dir
bzw. deiner Anwendung dann aber egal sein.

Gruß, Thomas [MVP ASP/ASP.NET]
http://www.69grad.de - Die ASP.NET-Profis aus Nürnberg
http://blog.thomasbandt.de - Privates Blog

Ähnliche fragen