Question

Does it make sense to use .NET DataSets even in applications that use a local in-process database for application data persistence?

If DataSets are mainly meant for in-memory caching of database results, it sounds like they’re not so beneficial when using something like SQL Server Compact local database that runs in the same process as the application.

Are there any other reasons to use typed DataSets? Say, do they ease WPF data binding?

Answer 1

Let me try to answer my own question.

It seems to me that DataSets were designed for use-cases such as this:

1. Data is loaded from a remote DB to an in-memory cache (the DataSet).
2. The cached copy is operated on in non-trivial ways (multiple tables, delete, add, update) without an active connection to the database.
   • DB relations need to be modeled into the local cache to enable these operations.
   • Data binding to the UI (e.g., WPF) is trivial because we’re working on in-memory copy of the data.
3. The cached copy is sometimes updated to the remote DB for true persistence.
   • This may happen for example when the client returns to online state or the user presses ‘Apply’ to truly commit his data.

With local in-process databases, there’s no need for the ability to work completely offline — the local DB connection is always available. This would suggest that modeling (potentially) complex DB relations into the local cache to enable add, delete and update is unnecessary. Rather, one would directly modify data in the database and only maintain a custom local cache for viewing the data. The local cache could be decoupled from the DB layer and put into its own ViewModel layer (MVVM).