How to write a simple ADO.NET ORM by using Linq and extension methods (in 10 minutes)

The article is nice and really shows off the features of C# 3.0 and LINQ, but I have a feeling you're trying to use all the features, even if there are better ways to do things.

Here's an example that I feel is not good:

var result = from u in connection.GetObjects<User>("select * from [USERS]")
    where u.Name == "Alex" || u.Name == "Christian"
    orderby u.Name ascending
    select u;

var result = from u in connection.GetObjects<User>(
    @"SELECT * FROM [Users]
      WHERE Name IN ('Alex', 'Christian')
      ORDER BY Name ASCENDING")
    select u;

TommyCarlier wrote:



The article is nice and really shows off the features of C# 3.0 and LINQ, but I have a feeling you're trying to use all the features, even if there are better ways to do things.

Here's an example that I feel is not good:

var result = from u in connection.GetObjects<User>("select * from [USERS]")
    where u.Name == "Alex" || u.Name == "Christian"
    orderby u.Name ascending
    select u;

This will select all records on the server and send them to the client, where the client will filter them. This is a horrible thing to do. The filtering should definitely happen in the database, like this:

var result = from u in connection.GetObjects<User>(
    @"SELECT * FROM [Users]
      WHERE Name IN ('Alex', 'Christian')
      ORDER BY Name ASCENDING")
    select u;

Chadk wrote:

It's surely better to filter on the server rather then the client. But how big a difference does it make performance wise?

Having played a little with the LINQ to SQL O/R designer, I think you're reinventing the wheel here. Especially with those attributes; there's already a TableAttribute and a ColumnAttribute. And contrary to your example, when using LINQ to SQL the LINQ expressions will get translated to SQL and run against the DB server.

I have the suspicious feeling that this LINQ to SQL stuff is going to replace my home-grown ORM once it comes out.

Plus you can get LINQ to SQL to use stored procedures for its default update/insert/select operations by just dragging them from the server explorer to the O/R designer. Ultra-cool.

Cool.

SecretSoftware wrote:

but the auto-generated myDBContext class, is a bit not easy to read.

Sven Groot wrote:



SecretSoftware wrote:but the auto-generated myDBContext class, is a bit not easy to read.

Since when are you supposed to read auto-generated code? If a code generator tool does it job well, you should never have to look at the generated code.

Sven Groot wrote:



Having played a little with the LINQ to SQL O/R designer, I think you're reinventing the wheel here. Especially with those attributes; there's already a TableAttribute and a ColumnAttribute. And contrary to your example, when using LINQ to SQL the LINQ expressions will get translated to SQL and run against the DB server.

I have the suspicious feeling that this LINQ to SQL stuff is going to replace my home-grown ORM once it comes out.

Plus you can get LINQ to SQL to use stored procedures for its default update/insert/select operations by just dragging them from the server explorer to the O/R designer. Ultra-cool.

littleguru wrote:



Sven Groot wrote:Having played a little with the LINQ to SQL O/R designer, I think you're reinventing the wheel here. Especially with those attributes; there's already a TableAttribute and a ColumnAttribute. And contrary to your example, when using LINQ to SQL the LINQ expressions will get translated to SQL and run against the DB server. I have the suspicious feeling that this LINQ to SQL stuff is going to replace my home-grown ORM once it comes out. Plus you can get LINQ to SQL to use stored procedures for its default update/insert/select operations by just dragging them from the server explorer to the O/R designer. Ultra-cool.

Isn't DLinq or "Linq to Entities" not going to be cut in the final version? I thought it's going to be removed in the final version and coming some time later?

littleguru wrote:



SecretSoftware wrote:Its not going to make it, it will ship after Orcas is Gold. At least thats what Andres said in his LINQ Presentation at MIX 07

ADO.NET Entities Framework == DLINQ?

It looks similar, but doesn't seem to be the same... or is it the same, just renamed to a better name?

Found answer: http://msdn2.microsoft.com/en-us/library/aa697427(vs.80).aspx - last paragraph says that Linq to SQL is a direct thing, where ADO.NET Entity Framework adds an abstraction layer.

Excellent article, littleguru.

Thanks.

Great article.  Really elagant code.  I will try this approch to cut down on code in one of my projects.