There are many database application development approaches, each with its own advantages and drawbacks. This topic describes some of database application design patterns applicable with dotConnect for Oracle and lists their tradeoffs to help you decide which one best suits your development needs.
One of the key questions in database application development is which set of components to base on. To answer this question it is necessary to clarify the following aspects:
Let's see how these questions are handled in standard ADO.NET approach and some advanced ways offered by dotConnect for Oracle.
The classic ADO.NET solution is to use typed datasets. This way you build your schema with standard DataSet, DataAdapter, and TableAdapter objects. The schema is created and edited with DataSource Wizard, DataSet Designer, and stored in a separate project item. The schema can be also edited with Devart DataSet Wizard in compatibility mode.
To bind the data access components to GUI controls use the standard BindingSource component. Forms with data-bound controls are designed with DataSources Window. In run time instances of connections and datasets should be managed manually (almost no automation). The typed dataset creates individual connection for every DataTable object basing on the connection string stored in the schema or in a configuration file.
To sum it up, the standard way requires much of manual coding, and offers very few design time features. To overcome this problem dotConnect for Oracle provides alternative solutions, which have greater capabilities in design time application development and reduce volumes of necessary coding.
The most comprehensive solution is to use typed OracleDataSets. The OracleDataSet components use OracleDataTable components to build a schema with support for Oracle-specific features. The entire schema is stored in separate project item as well. It is created with DataSet Wizard, and edited with DataSet Wizard or standard DataSet Designer.
To bind the data access components to GUI controls use the advanced DataLink component. The multiform data binding is managed with Devart DataSet Manager. In run time all components related to data access can inherit references from design time. Due to the InterForm technology, the components can reference connections and data sources even on other forms. The OracleDataSet can have either individual connections for every OracleDataTable, or single OracleConnection that is used by all tables. The connection can be controlled by the schema or by the OracleConnection component itself.
In general, typed OracleDataSets represent centralized data access and storage solution that provides rich set of design-time tools for working with the schema. However, typed OracleDataSets, as any other typed solution, is not much customizable in run time. Thus if you prefer to control the schema within run time, the untyped OracleDataSets solution might suit you better.
To migrate from a standard typed DataSet, change its Custom Tool property to dcOracleDataSetGenerator, then restart the tool or recompile the project.
Untyped OracleDataSets represent a more flexible alternative to typed OracleDataSets. The schema is built again with the OracleDataTable components encapsulated in a OracleDataSet component. The entire schema is stored in a OracleDataSet component that resides on a project form. It is created simply by dropping the OracleDataSet component from the toolbox, and edited with design-time OracleDataSet Editor or OracleDataTable editor. The solution uses standalone OracleConnection to connect to database.
In other aspects, such as data binding and reference management, the untyped OracleDataSets retain benefits of typed OracleDataSets.
The main difference between typed and untyped OracleDataSets is schema representation. With untyped OracleDataSets it is less convenient to customize the schema in design time, but the run-time schema management is much more powerful.
The individual OracleDataTable component can represent just one table or stored procedure, so it is not a direct replacement for typed or untyped OracleDataSets. However, it is a pretty simple and effective solution when you need to manage only small amount of tables.
The OracleDataTable component is created simply by dropping it on a form designer from the toolbox. You can edit it with design-time OracleDataTable editor. It uses standalone OracleConnection to connect to database. In data binding and reference management the OracleDataTable component has same advantages as typed or untyped OracleDataSets.
The advantages and disadvantages of individual OracleDataTable components are immediate consequences of its purposes. This is very simple and yet potential solution for very small schemas.
The Devart data access approaches allow you to move the development process from run time to design time, which is way more comfortable. The design time development is additionaly supported by the following features.
Live Data
dotConnect for Oracle supports connected data access model, so when you open an OracleDataTable object in design time, you have the actual data immediately. With the data displayed you can customize grid columns, cells format, and the overall appearance of your application without even launching it.
dbForge Fusion for Oracle
dbForge Fusion for Oracle is a powerful add-in designed to leverage, automate, and simplify Oracle database development process. Its design time capabilities provide you the following benefits:
dotConnect for Oracle offers solutions that are much more comfortable than the standard way of designing database applications. The solutions allow better control over connection setup, data retrieval and management. With Devart approaches you can employ all the advanced features of OracleDataTable component. Moreover, you can cut down development time even more with usage of dbForge Fusion.
OracleDataTable Advanced Features | InterForm Technology | DataLink Component Architecture | Developing Database Applications with dotConnect for Oracle | OracleDataSet Reference | OracleDataTable Reference