Idea for Resharper 4(.5?)

Having switched to .NET 3.5 and VS2008 I've recently starting using Linq, and it's really cool.

But it seems to me MS has really screwed when it comes to maintenance. If you use the Linq SQL integration, generating code from a database is really easy. You just pull stuff into the designer, and magic happens. The nasty bit is that if you later change your database schema, you're basically screwed. Your only option is to delete the designer file and do all that dragging over again. That's a pain in the ass if you had to rename things, which is usually the case.

The Visual Studio team -- by creating a tool which is virtually useless in it's default mode -- has left the market wide open to the clever people of JetBrains. It seems the Linq team has committed the same blunder. Or maybe they don't care, I don't know. But still, maintaining Linq based code will be really painful, and for us non-consultants who actually care about our software after we've released the first version, this sucks.

Therefore, dear JetBrains, I hope you will put your brilliant minds to work and make Linq usable, just as you've made VS2008 usable. Maybe you can do this for ReSharper 4.5, or perhaps create "ReLinqer"? I'm pretty sure there's a big market waiting for you here :)

5 comments
Comment actions Permalink

The LINQ for SQL DBML designer is unusable, not only because of the update issues you mention, but for a number of other issues:
- you have to keep all your tables in one single DBML file, otherwise you cannot have associations between the separated tables.
- if you have more than around 10 tables, the code behind file will be VERY big an almost unusable, especially with R#.

for these reasons, the DBML designer - as is today - should not be used in any real world project anyway. We use code snippets instead to create the LINQ entities.

0
Comment actions Permalink

SQLMetal, teh command line tool, is useful for regenerating. But is suffers from the "all code into one file" problem. I generated a 24K line C# file out of a moderate 70 table database.

We are using CodeSmith, starting with the PLINQO project on CodePlex to handle these issues. One interesting thing - the ORM designer is fine for editing large models (large dbml files) - it is very quick. So if you use the command line to get you DBML file you are fine. You just need code generation to user the DBML file to generate entities into separate own files.



HTH - jlo

0
Comment actions Permalink

I've had success with CodeSmith and these templates



It generates 1 file per table, lets you update names in the mapping file that persist for each regeneration, etc.

I haven't tried them with the free version of codesmith, but they're supposed to work with it.

0
Comment actions Permalink

We've been using LLBLGen Pro as our O/R mapper for a number of years now. Recently the next version of this product has gone into beta which adds Linq support (remember Linq is an integrated query language whereas Linq to SQL is one of Microsoft's O/R mapping products - the other being Entity Framework - which uses the Linq query language for querying. Linq and Linq to SQL are different things but you often see Linq to SQL incorrectly being referred to as Linq).

This new version of LLBLGen Pro also includes the ability to generate Linq to SQL code via its customisable templating mechanism - class per table. (See a description here). The advantage is that you can use the LLBLGen Pro designer which has excellent schema refresh capabilities (note that schema refresh isn't a simple task particularly when you start renaming tables and columns, moving references etc). LLBLGen Pro's designer does a good job of figuring out what you've done and making adjustments accordingly. It can also handle large projects in the thousands of tables.

You can then choose to use either Linq to SQL code (and so the Linq to SQL O/R mapping engine) or use Linq syntax and the LLBLGen O/R mapping engine which tends to produce more efficient SQL and generally has better performance. It also handles more querying scenarios. See this series of posts by its author.

Looks like a lot of people are filling the gaps left by Microsoft. Linq to SQL is still a V1 product.

Edited by: Tristan Bates on May 7, 2008 4:27 AM

0
Comment actions Permalink

I second LLBLGen.

It has its flaws and limitations (too much generated code, unnecessary
difficult naming of classes, no Visual Studio integration, the pre-LINQ
querying model has a very steep learning curve) but it's a mature and
powerful tool.

Wiebe Tijsma

Tristan Bates wrote:

We've been using LLBLGen Pro as our O/R mapper for a number of years now. Recently the next version of this product has gone into beta which adds Linq support (remember Linq is an integrated query language whereas Linq to SQL is one of Microsoft's O/R mapping products - the other being Entity Framework - which uses the Linq query language for querying. Linq and Linq to SQL are different things but you often see Linq to SQL incorrectly being referred to as Linq).

This new version of LLBLGen Pro also includes the ability to generate Linq to SQL code via its customisable templating mechanism - class per table. (See a description here). The advantage is that you can use the LLBLGen Pro designer which has excellent schema refresh capabilities (note that schema refresh isn't a simple task particularly when you start renaming tables and columns, moving references etc). LLBLGen Pro's designer does a good job of figuring out what you've done and making adjustments accordingly. It can also handle large projects in the thousands of tables.

You can then choose to use either Linq to SQL code (and so the Linq to SQL O/R mapping engine) or use Linq syntax and the LLBLGen O/R mapping engine which tends to produce more efficient SQL and generally has better performance. It also handles more querying scenarios. See this series of posts by its author.

0

Please sign in to leave a comment.