| 

.NET C# Java Javascript Exception

2
Hallo Coder,
nun, da ich ein schönes Datenbank Projekt habe, mit dem wir sowohl schick deployen und Schema Files vorhalten können als auch eine saubere Integration in unseren TFS haben, kommt der nächste logische Schritt: Verwendung des ja nun bekannten Schemas im Anwendungscode.

Bisher verwendete unsere Anwendung einen Webservice, der eine Datenzugriffsschicht hält, die sehr fehleranfällig bei DB Änderungen ist. Egal ob diese Schicht in einem WS oder direkt in der Anwendung sitzt, was ich nun möchte ist aus meiner Sicht völlig nahe liegend: Intuitiv versuche ich zB in einem Windows-Forms Projekt nun einen Verweis auf mein Datenbankprojekt herzustellen, damit auch DORT die Datenbankobjekte OHNE a) nicht validierbare SQL Statements und b) OR-Mapper angesteuert bzw. validiert werden können.

Ist das abwegig? Man kann jedenfalls nicht "einfach" die Schema Datei oder das DB Projekt als Verweis anbinden (so wie ach innerhalb der DB Projekte), so dass VS ebenso wie im DB Projekt selber feststellen kann, ob der Zugriff auf ein DB Projekt, um auf DIESER (korrekten) Grundlage die entsprechenden Abfragen zu schreiben.

Das Entity Framework würde nun hingehen und von der bereits deployten Version des DB Projekts das Schema rückwärts wieder abziehen und in Klassen "umwandeln". Nach ausdrücklicher Anweisung dies (objetkweise) zu tun. D.h. wann auch immer ich gegen das EF programmiere, ich hätte ggf. meistens gar nicht die neuste Version, da das EF selber wiederum nach der Veröffentlichung der DB Änderungen ja aktualisiert werden muss und das, obwohl das aktuelle DB-Schema ggf. sogar innerhalb der SELBEN Solution als DB Projekt vorhanden wäre... Ich halte das für unnötig kompliziert. Und obendrein bin ich nach meinen bisherigen Erfahrungen mit dem EF sowieso (noch) kein großer Fan davon.

Wie macht ihr das, gibt es hier einen einfachen Weg meiner Datenzugriffsschicht die Syntaxprüfung gegen das AKTUELLE Schema zu ermöglichen?

MfG
News:
01.08.2012
Magier77 238 1 6
2 Antworten
1
Hallo,

Ist das abwegig?

Ich sag ja. Die Datenbank sollte ja nicht so wild geändert werden, dass das Schema nicht mehr abwärtskompatibel ist. Und wenn doch, dann sollte auch im Sinne der Versionierung der Benutzercode explizit angepasst werden.

Werden im Schema nur Objekte umbenannt, so kannst du dir auch mit CREATE SYNONYM helfen, damit der Benutzercode gleich bleiben kann.

Wenns in den Anfeigszeit der Entwicklung ist, also wo das Schema nocht nicht klar herausgearbeitet ist und sich klarerweise öfters ändern kann, so würde ich einen Model-First-Ansatz gehen. Mit dem EF entweder per Designer od. noch lieber mittels Code-First (ab EF 4.1).

mfG Gü
01.08.2012
gfoidl 9,4k 3 5
0
Hallo gfoidl

danke für dein Feedback!

Die Datenbank sollte ja nicht so wild geändert werden, dass das Schema nicht mehr abwärtskompatibel ist. Und wenn doch, dann sollte auch im Sinne der Versionierung der Benutzercode explizit angepasst werden.


Hmmm. Durch den TFS und dessen Versionierung bin ich doch jederzeit mit jeder Version kompatibel. Eine Version besteht m.E. immer aus allen Schichten, enthält also auch die DB Struktur dieser Version.

Ob nun wild oder nicht wild, ist das nicht sekundär? Ich meine Anwendungen die über Jahre weiter entwickelt werden leben nun einmal insbesondere von Veränderungen [idealerweise Verbesserungen ;) ].

Klar sollte/muss der Benutzercode dann angepasst werden. Es geht ja auch genau um die Frage: welche Folgen hat die Schema Veränderung ggf. und wieso hilft der Kompiler mir eigentlich nicht [unmittelbar], kritische Codestellen zu finden und zu bewerten, ohne vorheriges Deployment des Schemas und Modellaktualisierung in EF.

Das Entfernen oder Verändern oder Umbenennen eines Objekts, z.B. einer Tabelle, hat eben Konsequenzen, die in dem Fall dann ja auch gewünscht sind. Es wäre dann ja schon schön, wenn der Kompiler das Fehlen eines Objekts unmittelbar auch bemerken würde, ohne dass der Anwendungscode erst zur Laufzeit das Fehlen der Tabelle feststellt, bzw. ich erst eine Email an alle Anwendungsentwickler schicken muss, damit sie gewarnt sind sich das Schema neu zu holen, lokal zu deployen und dann rückwärts in ihr Applikationsprojekt zu laden. So ist es ja leider beim EF vor DB Deploy und Modell Aktualisierung.

Gut, ich gebe zu, in diesem Szenario hat eine Person die Veränderung nicht in ihrer Gesamtheit durchgeführt und seinen (den DB Teil) rücksichtslos eingecheckt. Nicht nett, aber immerhin problemlos durchführbar... denn die beiden Projekte/Solutions (DB / Anwendung) sind nicht miteinander verbunden (=> Thema Verweis) und kennen sich somit eigentlich leider gar nicht.

Ich finde das reichlich umständlich. Gibt's in VS 2012 vielleicht Neuerungen? Konnte es bisher noch nicht untersuchen.

Viele Grüße, M
02.08.2012
Magier77 238 1 6

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH