Negli ultimi giorni chissà quante volte l'ho letto, mo' mi sono stancato...:-)
Ripeto:
Linq to SQL non è un Active Record.
Linq to SQL è un ORM puro.
da Fowler:
"An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database"
E ora veniamo a noi, ecco qualche concetto takeaway da memorizzare e studiare a casa:
1. L'Active Record definisce che la responsabilità del ciclo di vita di una entity è sulla entity stessa. In Linq to SQL la responsabilità è delegata al DataContext (come in un qualsiasi ORM che si rispetti). Nella implementazione di Caste.ActiveRecord infatti, tutte le entity derivano da una base comune che ha i metodi .Save(), .Insert(), etc. etc.
2. L'Active Record prevede che la struttura della classe che rappresenta la entity sia più o meno simile alla struttura del record sul db (e da dove verrebbe il nome allora?). In Linq to SQL ci si può scostare enormemente, riusciendo a mappare tranquillamente la many-to-one e il l'ereditarietà (non è possibile avere per adesso Composizioni di oggetti mappati, aka Component per i NHibernettiani)
3. Linq to SQL ha un wizard che parte dalla struttura del DB. Questo non lo fa di certo un Active Record. Al massimo si può dire che il wizard è (giusto un po...:-)) datacentrico. Ma (come ho già dimostrato ampiamente ai community days) con Linq to SQL si può partire dalla classe entity e mappare o con attributi o con file XML.
Quindi:
mancanza di mapping 1 a 1 con la tabella...
responsabilità delle CRUD operation non sulla entity, bensì sul contesto di persistenza....
stop così.
ps: Se poi da li passasse il buon Raf, vi direbbe che Linq to SQL è uno strumento per costruire DAL...
Ok Raf non siamo in disaccordo...ogni ORM serve a scrivere i DAL....va bene così? :-)