I started out my professional programming career with a lessor loved language at the time called Delphi. One of the wonderful things about Delphi was that there was plenty of options to choose from to connect to databases: ADO, BDE, midas,DBX and a plethora of others. Each offered their own upsides and downsides but were usually chosen by developer religion or need. However, if the application developer properly abstracted and layered their application it was a simple matter to switch between connectivity options as everything extended from a few base classes such as TDataset.
When I moved to Java, I expected to have to give up this freedom since all database connectivity in Java was done through JDBC; however, I was pleasantly surprised. JDBC was simply a set of a few base classes and standards that were enforced by the vendor. To go one step higher than my beloved Delphi IDE most IDE vendors programmed tools wrapped around the base classes so that one plugin would work with most JDBC protocol vendors.
As time moved on, I sorely missed doing desktop development so I moved to a set of .net/mono development languages. One would expect that ADO.NET would follow along the same methodology of JDBC in providing a few base classes and standards that would be enforced; and at first glance it is. However, it seems almost all tool vendors program to concrete classes/implementations. For example, attempt to use an Informix or Ingress .net provider in the server explorer in the IDE or with the SmartCode code generator; sadly it will not happen. Everything you can possibly need can be pulled from the base classes so it leaves me scratching my head.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment