Paul Gielens:ThoughtsService

another Endpoint to my thoughts

News

Syndication

  		•

Ads


Favorites

Projects

Why LINQ for SQL (DLinq)?

There are hardly any enterprise applications not manipulating structured information in any way. Most often this information comes in the form of business documents as structured XML or set-based information retrieved from relational databases. The .NET platform offers related but distinct API’s to manipulate this structured information. We have used these API’s to build advanced and less advanced abstractions. These abstractions are responsible to ferry information between our enterprise specific domain models and structured data sources. One of these abstractions is Neo which is a more advanced one. It lives on top of the .NET API’s providing a run-time infrastructure for managing structured information as objects. Although it makes enterprise applications a lot easier to maintain and sometimes easier to build, it has fundamental flaws just as all the other abstractions have. The most important flaw in these abstractions is that they solve the right problem in the wrong place.

To come back to the central question: why LINQ for SQL? It doesn’t matter whether LINQ solves the problem in the right way (this won’t make me popular with the abstraction vendors). It does however solve it in the right place: our language, Frameworks and tools.
Posted: Jul 16 2006, 02:09 PM by p.gielens | with 3 comment(s)
Filed under:

Comments

D. Appel said:

While these tools offer some increases in development speed, I find that the main flaw of most is that they make it harder to use the full power of the database. And, as you mentioned, most applications get some or all of their information from a relational database so it's clearly important to be in control of that.

On the other hand, when we started using VB (I'm talking pre-.NET-era here) the C++ guys were also balking at the performance penalties that productivity improvements couldn't outweigh.

So I think that as long as the marketpenetration of these (let's call them:) O/R mappers is not very high we should at least look at them as a solution to a non-percieved problem OR as an unfamiliar alternative to a feeling of uneasiness about the current solution.

It's either that or I've been sitting in the sun for too long.

# July 16, 2006 8:58 AM

FransBouma said:

Speculation: They keep Linq for Sql because it can be they can't get Linq for Entities finished on time in full force.

But that's just speculation from my part. Linq for Entities is the future for MS, as it will be part of SqlServer vNext so Linq for Sql is just a temp solution. If they manage to finish Linq for Entities before orcas ships, I would be very surprised they'd ship Linq for Sql.

# July 16, 2006 9:48 AM

Steve said:

Just a tool really, ie. to make it easier to create data mapping patterns [Fowler].

One more step away from needing to code the plumbing.

Although, in the wrong hands, it will create a mess.  No different than any other tool  :)

# July 16, 2006 8:32 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)