Fog Creek Software
Discussion Board

Looking for Delphi "Best Practices"


I've recently moved from VB to Delphi and I love it. I'm looking for "Best Practices" for Delphi. I've read a few books and got the standard "nuts & bolts" approach typical of most books. Now what I want is a high-level view of how a well-structured Delphi app should be architectured. A few examples:

Data Modules are suggested for placing most of your database connections and data sources. Fine, but can they also be used for other "global" objects? More importantly, should they be?

How does one implement global singleton objects in Delphi? Where's the best place to instance them? In VB I often used "Sub Main()" in a module to  do all my initialization before showing the main form... What's the proper equivalent in Delphi (I've tried using the hidden .dpr file of the project; but Delphi doesn't seem to like it, the IDE crashing when that file is too heavily modified. Any pointers? Would a Data Module be the right solution?)

If you've got URLs, articles or good books suggestions; I'd love to hear about them.


Guy Gervais
Monday, November 11, 2002

I might be able to help a little here. Regarding initializing things before showing the main form, you can have an initialization and finalization section in any unit and that code will run before anything else. If you do that in the unit for the main form it I believe it will execute before the main form is even created. You could also put code in the Create method of the main form, which will execute before the form is shown.

I have some pretty heavily modified .dpr units in some of my projects. Are you sure there wasn't something wrong with the code you put in there? There isn't anything wrong with modifying those units.

I've seen Data Modules used many times for things other than database stuff. Seems like a good way to collect and organize non-visual components that don't need a form.

You might want to Google for "Delphi Singleton". I've seen a couple different approaches and in my case it's never really been worth the trouble. I've usually declared a global instance in the class definition unit, create it in an initialization section and free in finalization. It gives me the convenience of a Singleton in that most other units use the global instance (which is guaranteed to be there) but the flexability of allowing another instance of the class if necessary. I've never personally found a need for a true, strictly-enforced Singleton.

I've received a lot of help and collected various unexpected gems from Borland's newsgroups (, particularly borland.public.delphi.language.objectpascal.

Ryan Eibling
Monday, November 11, 2002

I think VCL's implementation of the Clipboard function is a great technique to implement a singleton. Look at the source for details.

As far as best practices in general, there are different camps of Delphi programmers. Data aware vs. non-data aware; feature data modules vs business objects. I could tell you what I do, but I really don't want to start that discussion. Whatever works for you seems to be the best practice.

As far as using components, there appear to be some generally accepted common practices, like, TDataSource components used to glue controls to datasets should go on the form, and TActionList components should go on the data module. These are things I'd like to have seen covered in more detail in the documentation.

Big B
Monday, November 11, 2002

My advice: keep it simple.

Delphi is the best development tool around for keeping things simple. True, it does support an immense number of cool features for developers to exploit, but they are easily separated from one another.

And if you can, stay away from those nasty DLLs, COM+, and .NET rubbish. Debugging is significantly easier if you only have a single EXE to worry about.

Also, check out DBISAM from - it's saved my ass many a time - and has some damn useful components too.

Angus Glashier
Tuesday, November 12, 2002

Thanks for your feedback, guys.

Concerning the modified .dpr bug: If I recall correctly, I finally traced down the bug to having set my Application.Title to a constant that was defined in another unit. The project could be compiled from the command line and ran fine; but the IDE would either crash upon loading the project. or the editor would go crazy while in the .dpr file... I tracked down the bug by googling; and that's where I picked up the tidbit about not modifying the .dpr. Maybe it's only the constant assignment the IDE doesn't like. I'll explorer further.

Putting ActionLists in Data Modules and DataSources with their controls makes sense. Although all the DB demos included with Delphi seem to keep the DataSources in the DataModules. I guess it comes down to a matter of personal preference.

As for keeping things simple, it's probably true; but as a Delphi newbie coming from VB; there's a huge inventory of tools to learn. I use to write a bunch of code in the Form_Resize event in VB; Delphi has anchors; cool. I can also handle Windows messages easily with Delphi; but then I find the ApplicationEvents control which is easier to use in certain circumstances... It's like working with from a small toolbox for years and then stepping in a completely furnished workshop. I know the tool I need is there somewhere; I just need to find it and learn to use it properly. And there always seems to be at least 10 different ways to get the job done; they can't all be equally good.

That's what I meant by "best practices". It would be nice to have a site arranged by task and commonly used practices for accomplishing that task. And not nuts & bolts stuff like "How to Access the Registry" "Use a TRegistry object." but more like "How to best separate the UI from the core functionality" "Use forms for this... Use DataModules for these... Put this ... in classes." etc.

Guy Gervais
Tuesday, November 12, 2002

I know how you feel. I think the tougher questions you have are really answered by experience. You have to write a lot of bad code and a lot of good code to get to a place where you can reliably design good code and avoid the pitfalls. The more code you write the better you'll get. You can get help on specific things from newsgroups and articles and, in my experience, the higher-level "big picture" will become clearer the more you write and the more complicated your applications become. There are too many ways to do everything to come up with any "this is always best" answers.

Ryan Eibling
Tuesday, November 12, 2002

You can find a lot about this kind of thing at:

The Unofficial Newsletter of Delphi Users

About Delphi

Additionally, there are a lot of wise and opinionated people at the Borland newsgroups, at news:// Specifically, the delphi.oodesign group is good for questions about patterns.

Good luck, and enjoy Delphi. :-)

Tim Sullivan
Tuesday, November 12, 2002

Saved my ass many times:

Szasz Attila
Tuesday, November 12, 2002

The JEDI Code Library has a lot of good source code.

Wednesday, November 13, 2002

*  Recent Topics

*  Fog Creek Home