Seit heute gibts Visual Studio 2008 zum Download via MSDN Subscription.

Schonmal versucht eine Manager-Klasse zu erzeugen die Insert,Update,Delete für die ObjectDataSource anbietet?
Nun die ODS bietet dafür mehre Möglichkeiten. Eine davon ist es das Object selbst zu übergeben anstatt unzählige Überladungen der Update/Insert/Delete-Methode zu erzeugen die noch dazu bei jeder Änderung der betroffenen Klasse apdatiert werden.
Besonders wenn die Applikation an Umfang zunimmst ist diese Variante ziemlich mühsam.

namespace Sample.Manager
{
    [DataObject()]
    public class PersonEntityManager
    {
        [DataObjectMethod(DataObjectMethodType.Select)]
        public bool GetById(Guid ID)
        {
            //Code to load (LINQ?)
        }

        [DataObjectMethod(DataObjectMethodType.Insert)]
        public bool Insert(Person p)
        {
        }

        [DataObjectMethod(DataObjectMethodType.Update)]
        public bool Update(Person p)
        {
            //Code to save (LINQ?)
        }

        [DataObjectMethod(DataObjectMethodType.Delete)]
        public bool Delete(Person p)
        {
        }
    }
}

Sieht doch mal recht, simple aus aber man wird schnell ferstellen, dass man auf einige Probleme stossen wird.
Eines davon liegt in der Natur des HTTP Protokolls. Es ist statuslos.
Wir bekommen daher beim Update/Insert/Delete immer eine neue Instanz des Entitys (im Beispiel die Klasse Person). Die ODS befüllt zwar schön alle Werte die es kennt (Werte aus den DataKeys sowie die Werte die "angezeigt" werden) jedoch bleibt der Rest unbefüllt.

Für uns ist es zu diesem Zeitpunkt leider unmöglich festzustellen, welche Werte tatsächlich geändert wurden vom User und welche lediglich die "Default-Werte" des Objekts sind ...

Mein bisheriges Workaround war die Änderungen mitzuprotokollieren (beim Setter des Objekts wird der Name des Propertys gespeichert)
In der Update Methode hab ich nun das orig. Objekt geladen, und lediglich die "tatsächlich" gesetzten Werte auf das orig. Objekt gemappt hat und dieses zum Speichern an den DAL weiterreichte.

Doch genau diese Funktionalität kann man in Verbindung mit LINQ nicht mehr (so einfach) verwenden, vorausgesetzt man möchte nicht auf LINQ-TO-SQL Desinger bzw. auf SQLMetal.exe zur Codegenerierung verzichten.

Was machen wir also? Die ObjectDataSource ein klein wenig anpassen.
Das Vorteil dadurch: Wir tausche in der web.config die orig. ODS durch unsere eigene Variante aus und müssen somit unsere einzelnen Websites NICHT anfassen oder Code einfügen. Selbst alle Design-Tools in VisualStudio können weiter benutzt werden.
Mehr dazu jedoch in Part 2.

Auf der VSone in München werde ich einen Talk zum Thema LINQ halten.

Ich freue mich.

Wie bereits im Oktober des letzten Jahres im Blog von Scott Guthrie angekündigt wurde, ist es nun tatsächlich soweit.
Der Source Code des .NET Frameworks wurde offengelegt.

Direkt aus Visual Studio 2008 kann nun in die .NET Libraries steppen. Wie funktionierts? Im Blog von Shawn Burke findet man die Antwort.

Wie Dinesh Kulkarni - seines Zeichen Programm-Manager vom LINQ-Project - vor kurzem in seinen Blog über eine gemeinsame Basis-Klasse berichtete hat man mit LINQ durchaus die Möglichkeit Vererbung abzubilden.

Doch leider ist nicht alles Gold, dass beim ersten Anblick glänzt. "Manche" LINQ-Querys gegen die vererbten Members scheitern danach.

Setzt man ein nun eine Abfrage gegen den DataContext ....

GUID ID; //Value from somewhere else ...
var DB = new MyDataContext(;
var res = from c in DB.Customers
Where c.ID == ID
Select c;

... ab, wird man unweigerlich mit dieser Fehlermeldung zur Laufzeit ...

Class member EntityBase.ID is unmapped

... belohnt.

Macht man sich die Mühe und castet c bei der Where-Abfrage in einen Customer, dann läuft die Sache wieder:

GUID ID; //Value from somewhere else ...
var DB = new MyDataContext(;
var res = from c in DB.Customers
Where ((Customer)c).ID == ID
Select c;

Eigenartiger ist auch, dass das selbe Phänomen TEILWEISE bei Lamda Expressions zu beobachten ist.

Folgendes Statement führt zu einer Exception

var c = DB.Customers.SingleOrDefault(p => p.ID == ID);

hingegen läuft

var c = DB.Customers.Where(p => p.ID == ID).SingleOrDefault();

einwandfrei.

Lange Zeit hat es gedauert und nun ist es soweit und ein weiteres Blog hat das Licht der Welt erblickt.