In general, LINQ to SQL is a pretty basic and O/R Mapper, providing a very low level of abstraction. I suggest having a look at Entity Framework v4 which is included with .NET 4.0/VS2010 (EFv3, included with .NET3.5 SP1, what a bit… meh).

Now the DataContext generated by LINQ implements IDisposable, and when i see a class that implements IDisposable i want to play nice and dispose any instance created. The problem is that all the repositories share – for a request – the same DataContext instance and also the results of some linq queries are stored in cache so i can’t really dispose of the DataContext at the end of the request since objects created by it might still exist in the cache and they hold a reference to the DataContext.

Going deeper in the DataContext story I’ve found out that you don’t really have to dispose it since it will not keep the db connection open only the while executing the query and retrieving the results. So in the end the conclusion was that it’s better, simpler to just leave it to the GC.

Still it feels strange to rely on the internal details of the DataContext … but i guess it’s one of the prices i have to pay for all the nice things that LINQ to SQL brings.

@Ben: Man, i hear you on the non nullable types.

However you can manage your own memory by using a factory and pointers ( allocate a byte block) in an unsafe block and manage your own heap. This is very useful for cases when you want no GC collections eg if you were writing a 3D app and want to manage your vertex buffers etc. I

Templates i can understand but few people actually understand some templates and Java passes with very poor generics.

My biggest gripes
-Non nullable types (Sing# has these)
-Immutable object support via an interface

VB 6 worked like that, and so obviously Microsoft considered very carefully if there was a way to bring it into .NET, and all that debate was played out nearly a decade ago. Here’s the conclusion that was posted to the original .NET mailing list back in 2000:

http://blogs.msdn.com/brada/articles/371015.aspx

One important point is that reference counting is NOT deterministic destruction.

The whole point of deterministic destruction is to be able to say with certainty that by the time control reaches a certain point in the code, a certain resource has been freed. But if somewhere else in the program is able to stop that from happening, then it is invalidated.

If you want deterministic destruction, you don’t want reference counting. You want C++ destructors (no reference counting) or IDisposable (no reference counting) or the Lisp/Schema “with” idiom (no reference counting).

Reference counting is typically a wrong-headed attempt to simulate a GC where a proper automatic GC is not available. The irony is that GC is usually missing from the environment due to “performance concerns”, and yet the alternative chosen usually runs slower than automatic GC. This is certainly true with reference counting.

Here’s a paper about an attempt to provide “deterministic” destruction via reference counting (which is a contradiction-in-terms):

http://bit.ly/1OHefw

They were surprised to find that C# programs ran an awful lot slower when using reference counting instead of GC. But if you understand just how amazingly fast the CLR’s GC is, this will not be a surprise.

In fact, F#, the new language being developed by Microsoft Research (origins in OCaml) has exactly the prefix syntax you want. Below is an example of the function you gave in F#’s syntax:

let CompressServerLog() =
use file = new FileStream(@”C:\archive.zip”)
use zip = new ZipFileStream(file)
zip.Addfile @”C:\ServerActivity.log”

The filestream and zipfilestream’s are disposed when the function ends and the two ‘use’ bindings go out of lexical scope. Lexical scope is created by indentation or optional syntax a la:
use file = new FileStream(…) in where the binding is scoped to the expression after the in keyword.

You can read more about F# at fsharp.net
http://msdn.microsoft.com/en-us/library/dd233240(VS.100).aspx has information on the ‘use’ binding and ‘using’ function.

I’ve been using F# now for a year and am quite pleased with it. If you enjoy using LINQ, then you’ll love F#.

private void CompressServerLog()
{
using (FileStream file = new FileStream(@”C:\archive.zip”))
{
using (ZipFileStream zip = new ZipFileStream(file))
{
zip.AddFile(@”C:\ServerActivity.log”);
}
}
}

Instead, I would like to write:

private void CompressServerLog ()
{
using FileStream file = new FileStream(@”C:\archive.zip”);
using ZipFileStream zip = new ZipFileStream(file);
zip.AddFile(@”C:\ServerActivity.log”);
}

And have it translated to the first example by the compiler. Allowing the ‘using’ statement to be an optional prefix for local variable declarations which would tell the compiler to dispose when out of scope would be quite a nice feature in my opinion. That would actually make using the curly brackets to create an inner scope actually useful for a change.