You may or may not have come across the ability within LINQ to SQL to have mapping to and from your own objects.

Microsoft has a mapping builder called sqlmetal, which is a code generation tool to generate the mapping automatically.

Here is a sample command line to generate the mapping file.

1

sqlmetal /server:. /database:mydb /map:mydbMappings.xml /code:code.dbml

There comes a time when you are using LINQ to SQL that you just have to find out what SQL is being generated, for what ever reason that is, here a a few ways to get the SQL you are looking for:

You can use SQL Server Profile to see the traffic going to and from the database

But if you are like me you want more control over your processes, so you can use the DataContext.Log, and output the log to a window, or in the case below the console window

One last method is to just write out an objects SQL, using the GetCommand, as seen below

What with Entity Framework around, I have been finding it quite hard to find any good information about the Framework, so I have started to compile a list of good resources

The ADO.NET Entity Framework Overview

Code Samples

Mike Taulty is Mr Entity Framework

Professional ADO.NET 3.5 with LINQ and the Entity Framework

Entity Framework Toolkits & Extras

Transparent Lazy Loading for Entity Framework

Whatare the differences between LINQ to SQL v LINQ to Entities, well:

LINQ to SQL uses tables as entities

LINQ to Entities allows me to write C# LINQ queries that run against a conceptual data model.

The following table provides a summary of the features within each LINQ object

So this means that LINQ to SQL uses a database model to create its entities, where as the Entity Framework work on a layer of abstraction above the data, this is a most important feature.  As most database changes are taken care of by the schema and mapping without requiring a change to the obect model - making it so you do not have to refactor and rebuild your objects.

The second difference is the Entity Framework has the ability to allow the entity inheritance and entity composition.  This means that you can create an entity that is composed of colums originating in multiple tables without any complex join logic.

In summary:

• If you want the added security of insulation and loose coupling from the underlying database schema to make your object model more resilient to change, use the Entity Framework
• If you find that you need the features of entity inheritance and entity composition, use the Entity Framework
• If you already have a large LINQ to SQL codebase that is running just fine without entities, you probably don't need to spend the time to refactor out LINQ to SQL to replace it with LINQ to Entities.
• If you want to run LINQ queries against an object model, but your object model is a 1:1 mirror of the tables in your database, you probably don't need the Entity Framework.