LINQ to SQL and Entity Framework Classes
218 words.
I’ve been starting to work a little bit with LINQ to SQL and now the ADO.NET Entity Framework* (to implement ORM** for UvMoney, my home banking system). There’s something that troubles me about both frameworks. Both require you to build a “model” of your database with a designer, from which strongly-typed classes are generated, which you can then use in your LINQ queries.
This is quite similar to the designer-built strongly-typed DataSets from .NET 1.1 and 2.0, which I never enjoy using very much because there always seems to be something just a little bit wrong with them. With ADO.NET, my preference has always been to build my own ORM classes. Which makes me wonder: How do I take advantage of LINQ to SQL and the Entity Framework while still building my own classes? I suppose I should give up on that line of thought before I start, because implementing my own ORM classes would essentially be duplicating what LINQ to SQL and the Entity Framework do.
- According to rumor, Microsoft will be concentrating on the Entity Framework going forward, so there is little point in spending much more effort learning LINQ to SQL classes.
** ORM is Object-Relational Mapping, which is a fancy term for the process of sticking database values into object properties and vice versa.
Sorry, new comments are disabled on older posts. This helps reduce spam. Active commenting almost always occurs within a day or two of new posts.