Posso anche essere d'accordo (anzi, lo sono decisamente) con Andrea e Dino, ma solo fintanto che li consideriamo come una sorta di guida all'implementazione. Allora sì che devo prendere spunto (giusto il paragone con le centurie), interpretandone il significato e adattandone però la struttura al mio problema specifico, magari disconstandomene fino ad avere un qualcosa di diverso. Che però non è più il pattern da cui sono partito.
Credo sia un concetto parecchio importante, e che richieda pertanto un certo rigore nelle definizioni e nel significato che si attribuisce loro. Perché? Perché i pattern hanno anche un'altra importante funzionalità, oltre quella di darci una traccia (più o meno aderente alla realtà) ad un problema ricorrente. Ossia quello di rappresentare *un dizionario*, un linguaggio che permetta a due progettisti di capirsi al volo quando parlano di un aspetto del design. E allora in questo caso la definizione dovrebbe essere precisa, talmente precisa da essere sicuri che se io propongo ad Andrea di soddisfare quel requisito tramite un Layer Supertype, o di utilizzare un DTO per esporre i dati all'esterno, o di gestire la persistenza tramite un Active Record (BUAHAH ecco che ci siamo), io e Andrea dobbiamo capirci al volo, senza nessun rischio di misunderstanding.
E allora dire che questo framework "è quasi un Active Record" mi fa storcere un po' il naso, perché o lo è o non lo è. Punto.
Tra l'altro, credo proprio che Linq To SQL sia un perfetto esempio di DataMapper, anzi, di MetaData Mapper, e che di Active Record non abbia proprio nulla. Perché, visto che citiamo Fowler, allora lui stesso descrive Active Record come
An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
My two cents...