Dan Miser - DLINQ and MSSQL

Sunday, September 18, 2005

In the current version of DLINQ, you can only target MSSQL. The architecure seems to be extensible enough to allow for DBMS vendors to provide their own DLINQ assemblies so that when you write DLINQ queries, you will be allowed to communicate to a variety of back-ends. See System.Data.DLinq.Provider.ProviderContext for the class that you can use to descend from in order to get your own DBMS supported. Talking with MS, it appears that they are hoping that each and every vendor will provide their own assemblies. I think this is a mistake for the following reasons:

First off, the current code in System.Data.DLinq.DataContext uses code in System.Data.DLinq.SqlClient. It essentially forces the ProviderContext to be SqlClient. This will have to be cleaned up and made more generic before a vendor can deliver something.
I believe it's time for MS to start providing tools that allow the developer to mix and match parts. Until MS does this, they will continue to develop solutions that work well with MSSQL, but will miss out on what other DBMSes can do. They need to take the lead by providing other DBMS versions so they can see where the holes in their current approach are. If they wait for the vendors, it will most likely be too late to change the code to do what needs to be done to support 3rd party DBs. It's a Catch-22. DB vendors will wait to write their assemblies until MS cleans up the code (see point 1 above), and see that doing this will yield positive returns. When they finally do this, it may be too late to have the DLINQ architecture changed to accomodate whatever specific hooks may be required to get first-class support of the 3rd party DB.
It doesn't appear that there is any registration/management code in place to allow for you to simply say: "I'd like to use MSSQL (or Oracle, or InterBase)". It seems that this would be resolved by which assemblies you reference in your code. But how well will this work when you want to target multiple DBs in your application?
Finally, the competition (i.e. Borland) already provides low-level multi-DB code in several cases, and has for years: BDE, DBExpress, and Borland Data Providers (BDP). If a company with a development team that is a minute fraction of MS's development team can deliver this, there's no reason MS couldn't do the same.

Sunday, September 18, 2005 10:14:00 PM (Central Daylight Time, UTC-05:00)

Monday, September 19, 2005 1:00:00 AM (Central Daylight Time, UTC-05:00)

I highly doubt this will happen... Why? Microsoft primary goal for living is not about making your life easier - it is about using Microsoft products. They aren't fighting for market share with VS, so why should they make their tools compatible with Oracle, DB2, Interbase, MySQL, Firebird, etc? MS does not want to help Oracle, IBM, or open-source by giving native connectivity right out of the box to some of their most despised competitors. SQLServer has been gaining market share on Oracle and I’m almost willing to bet my caffeinated beverages (I can’t code without so that is a big deal <g>) that they are not going to do anything to possibly slow that down.

Ryan McGinty

Monday, September 19, 2005 4:20:00 PM (Central Daylight Time, UTC-05:00)

"DLINQ Interoperablility with ADO.NET" might open up connectivity to any standard ADO.NET provider and may be BDP can plug easily there.

Also, looks like ObjectSpace is folded into DLINQ. I was hoping to see OLINQ :-)

Ramesh Theivendran

Tuesday, September 20, 2005 9:37:00 AM (Central Daylight Time, UTC-05:00)

Read the overview doc and impressed at what DLinq has to offer. Esp. pleased to see transactions and stored procedures as part of the design. This would be a welcome addition to the .net framework and ADO.

Ramesh

Friday, September 23, 2005 3:03:00 PM (Central Daylight Time, UTC-05:00)

I went to a talk at PDC from the old PM of ObjectSpaces. He mentioned the it was turning out to be too complex relative to what it was doing. IIRC, he said like 60% of the test cases that were reported as bugs were due to user error because of the external mapping file. I really liked the idea of OS, but alas, it was dead before it was born.

I agree that DLINQ will open up opportunities for others. They mentioned that 3rd party O/R companies are already digging into it to see how they can offer value above what LINQ offers.

And I would *love* to see BDP plugin to this. You know where to find me if you want to talk. :-)

Dan Miser

Wednesday, August 02, 2006 6:33:00 AM (Central Daylight Time, UTC-05:00)

nery nice article

השמה היי-טק

Comments are closed.