So we don’t need another blogger starting a discussion as too whether it’s the case or not but what I would like to say is this: if it’s true I would like to hear a full and clear explanation as to the reasons why they killed off L2S, it’s the least we deserve! If the suggestions are correct and this announcement is indeed a subtle notice of the long term plans to shelve L2S, then have the guts to say so clear and out loud, perhaps my previous sentiments were off course and I should apologise
to the signatories of the ‘you know what’ for behaving as indelicately as the accused would seem to be behaving here! I have personally invested quite some time into L2S and as a long standing developer on the MS platform I expect to be treated with a touch more respect than a veiled notice such as this. I can only hope that everyone suggesting L2S has died are terribly wrong and I would be thrilled to see MS make an speedy announcement to the contrary of the rumour to squash it good and quick. LINQ To SQL - Live Long and Prosper.
UPDATE: Daniel G posted this recently with some explanation, which doesn’t exactly thrill me either. No offence to Daniel but this is the equivalent of a developer in my organisation making product announcements to our clients. It does however support the notion that ‘meaningful’ progression of LINQ to SQL is not a discussion point for the future and the choices in picking your poison just got reduced by a one.
Final Update:
Tim has posted some clarification which seems to be reasonably clear on the subject. So how many ORM/s should we learn? I look forward to seeing how much of the so-called ‘not about ORM’ bits in EF are important to me. It’s time to start investing some time in EF!
In part 1 of this post I made the code available for a framework that I named Golden Gate, which provided the pieces to use a POCO approach in using the LINQ To SQL OR/M along with Specifications (for dynamic querying and equality testing) and Fetching Strategies (providing flexible load options to suit the eager or lazy load requirements). What was missing in the code download was an example that utilised the DataContext classes ability to provide lazy loading or deferred loading as it terms it. The code below demonstrates how to create your POCO entities to allow for this.
//For the One to Many side of a relationship
private EntitySet<RingtailPage> _pages;
public IList<RingtailPage> Pages
{
get { return _pages; }
set { _pages.Assign(value); }
}
//For the Many to One side of a relationship
private EntityRef<RingtailDocument> _document;
public RingtailDocument Document
{
get { return _document.Entity; }
set { _document.Entity = value; }
}
Whilst the use of the EntitySet<T> and EntityRef<T> dont exactly fit the purist POCO approach, it’s a small price to pay when you consider that access to them are wrapped by an accessor mutator that exposes the Entity in question or an IList<T> where T is the entity in question. Matthew Charles explains why EntitySet<T> and EntityRef<T> are required for LINQ To SQL lazy loading.
I recently compiled all the libraries from my most recent post on LINQ To SQL, into a Multifile Assembly so people could play with the bits without having to load up the projects that make up the POCO Framework which contains the Repository / Specification and Fetching Strategy libraries in it’s VS.Net solution.
The trick in creating a custom multifile assembly is to take all the files from the libraries that you wish to blend into one assembly, compile them into netmodules and then combine them all with the Assembly Linker otherwise know as al.exe. In my case the modules were as below:
and the last command I had to execute on the command line was:
al <module name> <module name> … /main:<method name> /out:<file name> /target:<assembly file type>
where the module names were from my list above.
One thing to watch out for if your a ReSharper user: the multifile assembly (your DLL compiled from the netmodules) may not be recognised correctly by intellisense in VS.Net 2008 and may report that it cannot resolve symbols. I didn’t dig into the cause of this problem however turning ReSharper off will stop the warning and code window highlighting but the problem does not stop VS.Net successfully building and executing your code nonetheless.
As you can see, the ‘Repository’ type is not having intellisense resolve it correctly and it is showing up in RED! But let me re-iterate that this will not preclude your code from building and running in VS.Net 2008 and turning off ReSharper will remove the intellisense problem altogether.
The multifile assembly for my previous posts code can be found here and if you browse it in Reflector you can see that it incorporates all the namespaces and code from the multiple projects in the LINQ To SQL going POCO solution.
So we don’t need another blogger starting a discussion as too whether it’s the case or not but what I would like to say is this: if it’s true I would like to hear a full and clear explanation as to the reasons why they killed off L2S, it’s the least we deserve! If the suggestions are correct and this announcement is indeed a subtle notice of the long term plans to shelve L2S, then have the guts to say so clear and out loud, perhaps my previous sentiments were off course and I should apologise
to the signatories of the ‘you know what’ for behaving as indelicately as the accused would seem to be behaving here! I have personally invested quite some time into L2S and as a long standing developer on the MS platform I expect to be treated with a touch more respect than a veiled notice such as this. I can only hope that everyone suggesting L2S has died are terribly wrong and I would be thrilled to see MS make an speedy announcement to the contrary of the rumour to squash it good and quick. LINQ To SQL - Live Long and Prosper.
