Take the 2-minute tour ×

If my question isn't clear, please help me improve it with comments.

I'm new to Delphi and dbExpress and I'm just getting acquaintance with TSQLDataset, TDataSetProvider, TClientDataSet and TDataSource classes.

The project that I'm working on uses this components in a way that feels strange to me. There is a huge data module unit that contains lots and lots of the quartet of classes previously described. I'm guessing that there are better (and more modularized) ways of doing this. DataSnap is used only to place this data module in a server application, so the clients access the data through it.

So, let me try to explain some of my doubts:

  1. What is the role of each one of this classes? I read the documentation but I can't get a practical insight on this subject (specially about TDataSetProvider).
  2. Which classes should be in the data module and which should be in my forms?
  3. Is it possible to create an intermediate layer to abstract my business model from my database setup (maybe creating functions that return immutable datasets?)?
  4. If so, is it wise to use DataSnap to do so?

I'm sorry if I'm not clear enough. Thanks in advance.

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted


TDataSource is the bridge between data-aware controls and the dataset (TDataSet descendant) from which they are to get their values.

TClientDataSet is one such dataset. TClientDataSet can be used in isolation, for example to access data contained in xml files, but can also be hooked up to a TDataSetProvider.

TDataSetProvider is the bridge between the in-memory TClientDataSet and the actual dataset that takes its data from a database through some kind of driver. In Client Server development you will usually see a TRemoteDataSetProvider (name may be different, I don't work with these components that often), which bridges the gap between the client and server.

TSQLDataSet is the actual dataset getting its data from some database.

It would feel strange to me to see this quartet all in one executable. I would expect the TSQLDataSet on the server side hooked up to the TRemoteDataSetProvider's counter part. However, I guess that with an embedded database it could be a way to support the briefcase model, which is where TClientDataSet is really helpful (TClientDataset is very powerful, that is just one of its strong points.)

Single datamodule

Ouch. A single huge datamodule is lazy programming or the result of misconceptions about how to use datamodules. It is perfectly normal to have a single datamodule that "hosts" the database connection which is then used by various other datamodules that are more tightly focused on aspects of the application.

Domain abstraction

With regard to abstracting your business model, dbexpress and datasnap should really not be anywhere in your business model. They should be part of your data layer.

TDataSource, TClientDataSet and custom TDataSetProvider descendant(s) can be used to leverage the power of the data-aware controls in the UI while still keeping the UI separate from the business model. In this case the custom TDataSetProvider would be the bridge between the client dataset and the collections and instances in the domain layer.

Even so, I would still expect to see a separate data layer, using TRemoteDataSetProviders or straight TDataSet descendants (like TSQLDataSet) to provide the domain layer with its data.

The single huge data module you mentioned could be part of that data layer, with the client datasets providing the business layer with its data. As you also mention TDataSource as part of a common quartet, the application was probably developed in a RAD-data-aware fashion where UI controls are basically hooked up straight to database columns/tables.

If you want to transform this application to have a more layered architecture, tread carefully and slowly. Get to know the current architecture first and get to know it well enough to see the impact that this kind of transformation would have. The links provided by Serg will certainly help you there. Pawel Glowacki has written extensively about DataSnap.

share|improve this answer
So, in my client application, I would see only dataset providers, clien datasets and datasources? Another things: are the data modules a good place to implement a separate datalayer? Your answer is great and I think it could be a very good start point for people willing to develop database applications in Delphi. I myself have read the documentation, but couldn't put the pieces together until now. –  haole Oct 3 '11 at 0:19
@haole: yes, those are the components I would expect in a client app. Datamodules are fine to implement a separate datalayer. You do not need them though. I would just use "ordinary" units and instantiate the components at runtime, hooking up event handlers as needed through code (several questions on that here on SO). It has the added benefit not having a datamodule's dfm and all the sync/merge problems that come with dfm files and source control. –  Marjan Venema Oct 3 '11 at 7:26
add comment

The project you are working on is a Delphi Multitier Database Application

Your question is too wide for SO and hardly can be answered in its current form - you should learn to understand the underlying architecture.

You can start from video tutorial by Pawel Glowacki:



share|improve this answer
Those tutorials just show me how to place my database in a different application using DataSnap. It is not a concept abstraction: the UI still gets very tightly coupled with the database. –  haole Oct 3 '11 at 0:21
add comment

Your Answer


