Visto che da due giorni ci sto lavorando per una customizzazione su un nostro cliente...
la entity WorkItem (nel namespace Microsoft.TeamFoundation.WorkItemTracking.Client) del Team Foundation Server è un classico esempio di Active Record. Rappresenta una attività tracciabile in TFS e da cui scaturiscono una serie di metriche legate a tutti i servizi esposti, come il Version Control, la Build Automation, i Test. Il workitem è un concetto "core" di TFS.
Il workitem espone metodi che "tipicamente" si ritrovano in oggetti AR:
Open: Opens this WorkItem for editing.
PartialOpen: Opens this WorkItem for editing without transferring all the data about the work item over the wire.
Reset: Reverts all changes that were made to this WorkItem since the last revision.
Save: Saves this WorkItem after validating its contents.
SyncToLatest: Updates this WorkItem to the latest committed revision. All changes that were made to the work item from the last revision will be discarded.
Come si vede, le responsabilità CRUD sono affidate alla entity stessa.
La classe ha una discreta affinità con le colonne del database, ma il workitem essendo personalizzabile introduce anche delle hashmap per poter accogliere anche estensioni (una property Fields["campoEsteso"]). La personalizzazione del workitem internamente inserisce proprio nuove colonne, quindi non era possibile gestire tutto con delle property fisse.
Non esiste una Delete, perchè in TFS sia i workitem che gli item del source control sono critici per la ricostruzione delle versioni e non vengono mai cancellati, almeno da Object Model (nel 2008 c'è qualche funzione specifica in più per il destroy degli item).
Tutte le property, e sono veramente tantissime, hanno capacità di lazy loading. Nel caso di TFS questa è una saggia scelta perchè alcuni dei campi della stessa entity o correlati sono veramente pesanti, come gli attachment dei file che è possibile allegare.