LINQ to SQL (server)I've been looking more into the new Microsoft Entity Framework since I found out that LINQ to SQL is a technology that can be used with Sql Server (and should perhaps be called LINQ to SQL Server).LINQ to SQL Server translates the LINQ query to sql server SQL, and contacts the database where required (if the object isn't already cached, for example).Fortunately, LINQ as a technology in itself can be used with collections in general, and is not tied to a database at all (ie, you can create an IList<MyClass> and then query it using the LINQ syntax), and can be used with the Entity Framework (more on this later - lets get on with an overview).
Entity FrameworkThe traditional approach:
Lots of coding time and effort tends to go into moving the data in the domain (eg, a Customer) back and forth between the application and the data store. The entity framework is designed to solve this problem.
NOTE: The examples I'm using at present represent a 1 - 1 mapping between a data table and the application classes (as LINQ to SQL server), but the entity framework is able to map a data table to multiple classes, or multiple data tables to a single class, and map across multiple databases - these are major differences between LINQ to SQL server and the entity framework.Where the entity framework fits in:
The entity framework, in essence, is a library that allows mapping between your classes and your database. This mapping is achieved with three files:1. The .csdl file describes to the framework what your classes look like:
2. The .ssdl file - tells the framework what your database looks like.
3. The .msl file - tells the framework how to transform between the .ccsl and the .ssdl
These three files are xml files. They need to be found by your application, so you need to provide a path to them (whether they are external files or embedded resources). There are a number of methods of creating these files
- Type them in manually
- Code generate them using the command line tool
- Code generate them using the designer tools - this generates a .edmx file that contains all three files. The files are separated out into the output folder when you build.
When code generating using the command line tool, you can tell it to generate classes from the .csdl file (this is done automatically when using the designer tools) - these are partial classes and you can extend them as you wish.
LINQ to EntitiesNow we get to the fun bit - The entity framework has it's own query language (eSQL), very similar to SQL, that your code can use to retrieve classes from the database.As I understand it (someone correct me if I'm wrong) the provider that you specify in the configuration (eg. System.Data.SqlClient) translates the eSQL to the specific sql required by the database. This means that a third party can provide their own entity framework provider that will work with their database.Now, where as LINQ to SQL server translates the LINQ query to MS SQL, LINQ to Entities translates the LINQ query to eSQL - which is then translated into db specific sql by the provider. This means that you can use standard LINQ queries against the your entity framework model, with any database that has a provider (at present, only SQL).
ConclusionThis is only a high level overview based on my understanding so far. In the next part, I'm planning on creating a mapping between a basic database and some code.
Further resources:If you're interested in creating a managed provider, checkout David Sceppa's blog postMike Taulty has some useful posts on the Entity FrameworkTheServerSide has a good overview article (better than mine)