开发者

How to abstract my business model using dbExpress and Delphi (maybe DataSnap as well)?

开发者 https://www.devze.com 2023-04-10 06:59 出处:网络
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 TDataS

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 g开发者_运维问答uessing 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.


Components

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.


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:

http://www.youtube.com/watch?v=B4uxLLIUddg

http://cc.embarcadero.com/item/28188

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号