views:

348

answers:

3

I've just been researching the ActiveRecord pattern, and based on this (http://en.wikipedia.org/wiki/Active_record_pattern), it seems Linq 2 Sql more or less implements this, am I wrong? or what would need to be changed for it to conform to the ActiveRecord pattern?

+3  A: 

LINQ to SQL itself isn't an implementation of the ActiveRecord pattern. In a true implementation of Fowler's ActiveRecord pattern, the object itself would be responsible for saving and loading its state from the database. When using LINQ to SQL Objects, the DataContext is responsible for database retreival, tracking object state, and saving those changes back to the database.

You'd have a hard time wrapping those LINQ to SQL classes in more code to make it a true implementation of the ActiveRecord pattern (there's no easy way to take the responsibility away from the DataContext).

Justin Niessner
I'm not sure if that's entirely correct. The entity object and the DataContext share responsibility - the DataContext provides boilerplate functionality for translating generic attribute data into SQL, but the entity object provides the mappings between object members and the database. Also, the state of the entity *is* stored within the object - again, the DataContext only has generic, boilerplate functionality for reconciling state.
Rex M
You're right. But the point is, the responsibility is still shared rather than the object handling everything for itself (as you would in a true implementation of the ActiveRecord pattern).
Justin Niessner
Does linq to sql give the 'one class per table' mapping? That would be a characteristic of ActiveRecord. Which leads away from other OO patterns such as Domain Driven Design.
Brendan Kowitz
+6  A: 

In some ways it can feel like an active record pattern, but it really isn't. Basic example:

//load the entity
var c = myDataContext.Customers.FirstOrDefault(c => c.Id == 1876);
c.Name = "George Armstrong Custer";
 // saves the entity 
myDataContext.SubmitChanges();

Active record

//load the entity
var c = Customer.GetCustomer(9);
c.Name = "Varus";
//save the entity
c.Save();

Active record really just involves one class which covers the model and supplies the data interface Linq to Sql follows a different path where there are a few model classes and a separate data interface, otherwise known as a repository.

PS: For a good example of an ORM that uses the active record pattern, check out Subsonic.

Wyatt Barnett
+1 Its more clear when presented with example :)
Prashant
+2  A: 

LINQ to SQL is not an implementation of Active Record, which would mean the entities are fully responsible for managing their own persistence (i.e. Persistence Aware). What LINQ to SQL actually is is an implementation of Unit of Work. A Unit of Work means that some kind of registry or context tracks the state of entities, either implicitly or explicitly, allowing entities to be completely ignorant of their persistence mechanism (i.e. Persistence Ignorant).

Unit of Work support a programming style called POCO (plain old clr object), which helps you maintain separation of concerns and maintain the principle of single responsibility. When those two principals are met, your software is usually easier to maintain. Active Record actually breaks both of those principals, leading to more tightly coupled software that can be more difficult to maintain.

jrista
@jrista Interesting...
GONeale