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