database - Delphi DataModule Usage - Single or Multiple?

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I am writing an application, there are various forms and their corresponding datamodules.
I wrote in a way that they are using each other by mentioning in uses class(one in implementation and another in interface to avoid cross reference) Is this approach is wrong? why or why not i should use in this way?

You should re-write the title to more clearly indicate the nature of your question. You probably can't edit it, so I'll do it for you.... – Chris Thornton Nov 23, 2010 at 14:45 IMO, datamodules should never reference the project's forms. If a form needs to, for exemple, react to a change in a dataset, put a TDatasource on the said form, link it to the dataset and put your code in the TDatasource's event. – Ken Bourassa Jan 28, 2011 at 17:38 Coming back to questions like this years later, I find it interesting to note that in the absence of limits on how much you can shove in one form, data module, or unit, Delphi developers on average shove Way Too Much Stuff in One Module/Unit/File instead of thinking about what makes actual sense and is maintainable, and readable. – Warren P Oct 14, 2013 at 1:46 Warren.. coming to this years after your years, I think all developers need to get better educated in software design and better educated in computer science in general. Counting myself, there are still things I do not know that I should learn as well. – William Egge Aug 27, 2016 at 18:39

I have to agree with Ldsandon, IMHO it's way better to have more than one datamodule in your project. If you look at it as a Model - View - Controller thingie, your DB is the model, your forms would be the Views and your datamodules would be the controllers.

Personally I always have AT LEAST 2 datamodules in my project. One datamodule is used to share Actions, ImageLists, DBConnection, ... and other stuff throughout the project. Most of the time this is my main datamodule.

From there on I create a new datamodule for each 'Entity' in my application. For example If my application needs to proces or display orders, cursomters and products, then I will have a Datamodule for each and everyone of those.

This way I can clearly separate functionality and easily reuse bits and pieces without having to pull in everything. If I need something related to Customers, I simple use the Customers Datamodule and just that.

Regards,

Stefaan

It is ok, especially if you're going to create more than one instance of the same form each using a different instance of the related datamodule.

Just be aware of a little issue in the VCL design: if you create two instances of the same form and their datamodules, both forms will point to the same datamodule (due the way the VLC resolves links) unless you use a little trick when creating the datamodule instance:

  if FDataModule = nil then
  begin
    FDataModule := TMyDataModule.Create(Self);
    FDataModule.Name := '';  // That will avoid pointing to the same datamodule
A data module just for your table objects, if you only have a db few tables, would be a good one to be the first one. 
And a data module just for your actions is another. 
A data module just for image lists, is another good third data module.  This data module only contains image lists, and then your forms that need access to image lists can use them all from this shared location.
If you have 200 table objects, maybe more than one data module just for db tables.  Imagine an application that has 20 tables to do with invoicing, and another 20 tables to do with HR.  I would think an InvoicingDataModule, and HRDataModule would be nice to be separate if the tables inside them, and the code that works against them, doesn't need to know anything about each other, or even when one module has a "uses" dependency in one direction, but that relationship is not circular. Even then, finer grained data module modularity can be beneficial.
Beyond the looking glass. I always use Forms instead of DataModules. I know it's not common ground.
I always use Forms instead of DataModules. I call them DataMovules.
I use one such DataMovule per each group of tables logically related.
I use Forms instead of DataModules because both DataModules and Forms are component containers and both can effectively be used as containers for data related components.
During development:
My application is easier to develop. Forms give you the opportunity to view the data components, making easy to develop those components.
My application is easier to debug, as you may put some viewer components right away so you may actually see the data. I usually create a tab rack, with one page per table, and one datagrid on every page for browsing the data on the table.
My application is easier to test, as you may eventually manipulate the data, for example experimenting with extreme values for stress testing.
After development:
I do turn form invisible. Practically making it a DataModule, I enjoy the very same container features than a datamodule has.
But with a bonus. The Form is still there, so I may eventually can turn it visible for problem determination. I use the About Box for this.
And no, I have not experienced any noticeable penalty in application size or performance.
I don't try to break the MVC paradigm. I try to adhere to it instead. I don't mix the Forms that constitute my View with the DataMovules that constitute my Controllers. I don't consider them part of my View. They will never be used as the User Interface of my application. DataMovules just happen to be Forms. They are just convenient engineering artifacts.
                Forms are "heavyweight" compared to datamodules. Because they are actually OS "windows", they use system resources, they have a winproc, etc. etc. Datamodules are much more lightweight. See little need to show a form with only non-visible components. Yes, you can print some debug output to them, IMHO there are better ways to perform that.
– user160694
                Nov 23, 2010 at 19:04
        Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.