EF4: Zu meckern gibt es immer etwas

Im Rahmen meiner bisherigen Arbeit mit dem EF4 bin ich auf ein paar Dinge gestossen, welche dieses Framework nicht kann, die aber wünschenswert und sinnvoll wären. Ich führe diese hier auf, weil es eine nützliche Information sein kann zu wissen, dass etwas nicht geht – man kann dann nämlich aufhören nach einer direkten Lösung zu suchen und sein Ansinnen entweder fallenlassen oder damit beginnen, eine Umgehungslösung zu suchen.

Weil sich solche Dinge heutzutage schnell ändern können: Die folgenden Aussagen beziehen sich auf das Entity Framework 4, so wie in Visual Studio 2010 (original d.h. ohne Service Pack 1) enthalten.

  • Es gibt im Datenbank-Designer für das EF4 keine Möglichkeit, die Reihenfolge von Properties zu ändern, weder mit der Maus interaktiv (etwa via „Drag & Drop“) noch durch Änderungen im Eigenschaften-Fenster. Umgehungslösung: Direkt im XML hinter dem Designer herumpfuschen, so wie z.B. hier erläutert.
  • Arbeitet man Design First d.h. generiert die Datenbank ab Design, gibt es keine Möglichkeit, sich im Designer zu Indices zu äussern: Indices kennt dieser schlicht nicht, abgesehen von denjenigen für Primary Keys natürlich.
  • Ebensowenig kennt der Designer Unique Constraints.
  • EF4 unterstützt Enumerations nicht. Leute lassen sich hier alle möglichen Umgehungslösungen einfallen, wie z.B. diese hier, aber das grundsätzliche Problem schleckt keine Geiss weg, wie man hier in der Schweiz zu sagen pflegt. Etwas pikant ist an dieser Geschichte noch, dass LINQ to SQL offenbar Enumerations unterstützt.

Bei allen 4 aufgeführten Dingen erstaunt es mich etwas, dass man mit dem Entity Framework Release 4 erreicht, ohne eine Lösung anzubieten. Wenn man die Signale von Microsoft richtig deutet, ist ja das EF zumindest im Moment die favorisierte Datenbank-Zugriffs-Technologie für .NET-Programme und hätte darum Detail-Pflege sicher verdient.

Veröffentlicht in Allgemein. Schlagwörter: . Leave a Comment »

Debugging von ASP.NET-MVC2-Applikationen

Irgendwie ging immer alles schief, wenn ich Fehler aufspüren wollte in der Applikation, die ich gerade mit ASP.NET MVC2 entwickle: Z.B. bei der Verwendung eines Objekts, das fehlerhafterweise null war, stoppte der Debugger nicht am Ort des Fehlers, sondern irgendwo im MVC2-Code, dort nämlich, wo ein „hoch oben“ angesiedelter Handler per catch die resultierende Exception abfing.

Um noch eins draufzusetzen, hatte Visual Studio zudem etwas am entsprechenden MVC2-Source-File mit dem catch drin zu meckern, das es vom Microsoft-Source-Code-Server heruntergeladen hatte, irgendetwas mit Some bytes have been replaced with the Unicode substitution character while loading file, so wie bei StackOverflow hier beschrieben, notabene ohne Tipps zur Abhilfe.

Es gibt in Visual Studio eine Einstellung, mit der der Debugger gleich stoppt, sobald irgendeine Exception auftritt, unabhängig davon, ob ein catch dafür zuständig ist oder nicht, so wie hier beschrieben, aber dieser Mechanismus hat auch so seine Probleme:

Mit Debugging-Option Enable Just My Code nicht gesetzt gibt’s viel zu viele Exceptions, weil in MVC2 vieles über Exceptions abgehandelt wird, die man dann alle erst „wegklicken“ muss, bis schliesslich die eigene Exception drankommt, um die es eigentlich geht. Und mit Option gesetzt klappt’s mit Exceptions innerhalb von MVC2 nicht, die auftreten, weil man z.B. einer Methode einen Parameter als null übergeben hat, der definiert sein muss.

Die Rettung war schliesslich folgendes Vorgehen:

Man kann dankenswerterweise den Source Code von ASP.NET MVC2 bei Microsoft CodePlex hier herunterladen, in einer Form, über die Visual Studio nichts zu meckern hat. Und es ist überraschend einfach, diesen Code quasi als „eigenen“ Code in sein Projekt einzubinden, so wie hier beschrieben. (Die Beschreibung ist zwar noch für MVC1, es klappt aber auch mit MVC2.)

Für die Zeit der Entwicklung meiner Applikation habe ich nun an zwei Orten in diesem MVC2-Source-Code catch-Anweisungen auskommentiert, so dass der Debugger die meisten auftretenden Exceptions als unhandled taxiert und gleich stoppt. (So komme ich jetzt ohne die erwähnte untaugliche Option aus, die den Debugger bei jeder Exception stoppen lässt.)

Auch sonst ist es natürlich ganz interessant, ein paar Blicke auf diesen Source-Code zu werfen, und man findet im Netz etliche Kommentare von Leuten, die schwierige Probleme in ihren Web-Applikationen nur dadurch lösen konnten, indem sie anhand dieser Sourcen im Debugger verfolgten, was innerhalb ASP.NET MVC2 genau passierte.

Veröffentlicht in Allgemein. Schlagwörter: , , . Leave a Comment »