Microsoft has announced their intention to "de-emphasize" LINQ to SQL, and guided us to use the Entity Framework, instead. This is not too surprising, considering that LINQ to SQL was never supposed to exist in the first place. But, just like with WinForms, a lot of people have used LINQ to SQL in production code in no small part because the preferred solution wasn’t ready yet, and LINQ to SQL includes features which are not in the current released version of the Entity Framework.
This speaks to the importance of abstracting data access. The nice thing about object relational mapping is that once you’ve read the data, your data are just objects, whether or not they’re POCOs. You can and should emphasize this encapsulation by hiding the reading and writing behind a framework such as the Repository pattern. It is, IMHO, a mistake to ever call something like Context.SaveChanges inside of a controller.
{ 2 } Comments
Databases are expensive resources, I don’t think hiding the fact of writing an object is really a db operation a good idea. This opens door to make mistakes, and if there is a chance to make mistakes, the mistakes will be made.
tcmaster, using Repository doesn’t hide anything. Writing the object doesn’t update the DB automatically. You call a repository method explicitly to do this. The difference is that by not directly talking to the DB you can, e.g., use a non-DB repository for unit tests of the clients.
Post a Comment