Do you miss the simplicity of programming with ADO under Visual Basic 6? Are you tired of spending precious time creating and configuring ADO.NET DataAdapter, DataSet and Connection classes each time you make a change to your database? Is ADO.NETs disconnected model making your simple desktop application seem like a major enterprise programming task?
Infralution's Virtual Data Objects (VDO) may be the solution you have been waiting for. We give you back the simplicity and flexibility of the traditional ADODB programming model while allowing you to still take advantage of .NETs powerful data binding model.
VDO provides classes that wrap the standard ADODB Connection and Recordset classes allowing them to be used as fully featured data sources for .NET controls such DataGrid, ListBox, ComboBox and of course Infralutions own range of powerful controls.
It only takes two lines of code to populate a DataGrid like the one shown below - with no other design time configuration needed. If you decide to change your database schema there are no coding changes necessary!
Simplicity. For most desktop applications ADO.NETs disconnected programming model is just far too complex. VDO gives you back the simplicity of traditional ADO with out sacrificing the power of .NET data binding.
Performance. If your application involves browsing data from a large database then ADO.NET's in-memory model could be killing your performance and exploding your memory usage. VDO gives you lightning fast browsing on huge databases - particularly when coupled with Infralution's intelligent "Virtual" controls that only load the data necessary for the current display.
Price. At just $US 120 it isn't worth your while even thinking about home grown solutions. The time you would have spent reconfiguring Data Adapters and Data Sets each time you make a database change will cover the purchase price in next to no time.
With the advent of the .NET environment Microsoft introduced a new programming model, ADO.NET, to replace the previous COM programming model (Active Data Objects - now referred to as ADODB). ADO.NET was designed largely to meet the needs of large scale, distributed, web-oriented databases.
ADO.NET features a completely disconnected model in which data is loaded into an "in-memory" database (a DataSet). This model works well for the intended domain but has a number of short comings that make it awkward to use for traditional small scale, desktop applications.
Creating and managing ADO.NET classes is much more complex than ADODB. Typically you must create a Connection, configure Data Adapters, create a DataSet, set up Relations in the DataSet and the fill the DataSet with data. If you change the database schema you have to manually update the DataAdapters and DataSet. For small scale projects this overhead can completely outweigh any benefit the model might offer.
ADO.NET's in memory model means that it is difficult to build applications that allow an end user to efficiently browse a large database. ADO.NET puts the onus on the programmer to handle issues such as memory usage and paging of data.