BDP.WHY? Jun 24, 2004 05:44
I just attended a talk that Cary Jensen gave at the Washington DC Delphi User Group. He talked at some length about ADO.NET and BDP.NET. It was interesting because I thought that he might have tried to spin BDP.NET in an "I wear Borland underwear" light but was pleasantly surprised at his candor.
Tonight's presentation just reinforced my belief that BDP.NET is bogus. I'm not sure why Borland decided to pour R&D effort into building yet another database framework and yet another set of database drivers. Even if they are faster or support design time data (a feature I almost never use in Delphi Win32) or have better overall IDE integration, they are not worth it IMO.
It's yet another proprietary data access framework. Choosing BDP.NET is pretty much choosing to be at the mercy of Borland for database driver implementation. Based on the black box implementation of dbExpress drivers, Midas, and ClientDatasets in Delphi Win32, I'm not keen on putting my eggs in Borland's basket.
Why should I choose a Borland only solution when I can choose the .NET standard, ADO.NET, with virtually every database vendor producing free .NET providers for their databases? I don't see Oracle releasing a BDP.NET driver any time soon. It just doesn't make any sense to me. IMO Borland would have been better served in finding some way of integrating ADO.NET into the IDE as best as they could. Couldn't they have an ADO.NET data explorer instead of the BDP.NET one? Perhaps punt on design time data?
But here's the real kicker. It seems to me that the majority of .NET applications are ASP.NET ones. This is where .NET really shines. So where is the connection pooling in BDP.NET? Even if BDP.NET is the cat's meow at design time, without connection pooling it's pretty much in the litter box at runtime.
I hope Borland surprises me...but until then: ADO.NET.
Write a comment
- Required fields are marked with *.