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 PostgreSQL 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 PostgreSQL.
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 PostgreSQL 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 PgSqlDataSets. The PgSqlDataSet components use PgSqlDataTable components to build a schema with support for PostgreSQL-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 PgSqlDataSet can have either individual connections for every PgSqlDataTable, or single PgSqlConnection that is used by all tables. The connection can be controlled by the schema or by the PgSqlConnection component itself.
In general, typed PgSqlDataSets represent centralized data access and storage solution that provides rich set of design-time tools for working with the schema. However, typed PgSqlDataSets, 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 PgSqlDataSets solution might suit you better.
To migrate from a standard typed DataSet, change its Custom Tool property to dcPgSqlDataSetGenerator, then restart the tool or recompile the project.
Untyped PgSqlDataSets represent a more flexible alternative to typed PgSqlDataSets. The schema is built again with the PgSqlDataTable components encapsulated in a PgSqlDataSet component. The entire schema is stored in a PgSqlDataSet component that resides on a project form. It is created simply by dropping the PgSqlDataSet component from the toolbox, and edited with design-time PgSqlDataSet Editor or PgSqlDataTable editor. The solution uses standalone PgSqlConnection to connect to database.
In other aspects, such as data binding and reference management, the untyped PgSqlDataSets retain benefits of typed PgSqlDataSets.
The main difference between typed and untyped PgSqlDataSets is schema representation. With untyped PgSqlDataSets it is less convenient to customize the schema in design time, but the run-time schema management is much more powerful.
The individual PgSqlDataTable component can represent just one table or stored procedure, so it is not a direct replacement for typed or untyped PgSqlDataSets. However, it is a pretty simple and effective solution when you need to manage only small amount of tables.
The PgSqlDataTable component is created simply by dropping it on a form designer from the toolbox. You can edit it with design-time PgSqlDataTable editor. It uses standalone PgSqlConnection to connect to database. In data binding and reference management the PgSqlDataTable component has same advantages as typed or untyped PgSqlDataSets.
The advantages and disadvantages of individual PgSqlDataTable 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 Live Data features.
dotConnect for PostgreSQL supports connected data access model, so when you open a PgSqlDataTable 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.
dotConnect for PostgreSQL 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 PgSqlDataTable component.
PgSqlDataTable Advanced Features | InterForm Technology | DataLink Component Architecture | Developing Database Applications with dotConnect for PostgreSQL | PgSqlDataSet Reference | PgSqlDataTable Reference