Thoughts from Dan Miser RSS 2.0
# Monday, 19 September 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.
Monday, 19 September 2005 04:14:00 (GMT Daylight Time, UTC+01:00)  #    Comments [5] -
Tracked by: [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback]
<2018 May>
About the author/Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2018
Dan Miser
Sign In
Total Posts: 388
This Year: 0
This Month: 0
This Week: 0
Comments: 630
Pick a theme:
All Content © 2018, Dan Miser
DasBlog theme 'Business' created by Christoph De Baene (delarou)