The history of IT is littered with the corpses of software companies that assumed that a solution that worked well in particular circumstances would necessarily become a generic panacea. Who, for example, now remembers the past giants of the Workflow industry?

The Orcas chrysalis is now hatching into the Visual Studio 2008 butterfly. Well, most of it. Visual Studio 2008 and .NET FX 3.5 will ship before the end of November. The Entity Framework, vNext, isn't ready yet. There is a lot in Visual Studio 2008, and it will take time to assimilate. Language Integrated Query (LINQ) has had a lot of attention. It is a neat solution, but not to every problem. The concept is difficult to argue with: we have just one querying language for every source of data. Data sources can export their metadata to the application; we then create logical, object-oriented, data sources by mapping entity-relational models to the object model (which is where vNext comes in). The problems of having to learn a different query language for every data repository, XML, LDAP, array, enumerable class, dataset, in-memory object, relational database, document, ISAM (…and so on) suddenly vanishes.

However, what works well with an XML file, a dataset, or a low-volume data-store could, in fact, be a disaster for a commercial, high-volume online transactional processing system. The problem is that the cost of a harmonised and logical application interface is likely to be a cacophony of 'dynamic SQL' at the database.

It is true that LINQ and vNext Entity Framework can work with stored procedures, but recent Microsoft presentations have made little of this. In fact, the difference in tone at PASS and TechEd was striking, with the emphasis to the developers being much more based on making direct calls into the database at table level. If this comes about, then there will be interesting times ahead for the DBAs. The problems of tracking and correcting locking/blocking problems, rogue queries, performance problems due to poorly constructed queries or the flushing of the procedure cache, not to mention security issues, will keep them busy; so busy, they won't have the time to worry about the fact that they cannot change the entity/relationship model without breaking LINQ code.

vNext is probably going to be the vital technology for the data architect because it provides the means to present one rational Entity Data Model for the application, rather than maintaining separate EDMs for persistence, reporting (e.g. SMDL), analysis (e.g. UDM), workflow, or data management (e.g. SMO).

It seems likely (though at this stage, not certain) that one will be able to provide a logical interface between the EDM and SQL Server that is based on stored procedures, views and functions. The application developers will be able to LINQ into the data model, thereby avoiding what they refer to as 'impedence mismatch'. This looks a lot more like a solution that will please everybody.

So what are your thoughts on this contentious LINQ issue? Just add them as a comment below (you'll have to be singed in). Again, all contributions will go into the draw for an iPod Shuffle!

Cheers,

Tony.