Wondering about a new project, I find an interesting issue, is it possible to create a dynamic linking library datamodule as you can do with forms?
Wondering about a new project, I find an interesting issue, is it possible to create a dynamic linking library datamodule as you can do with forms?
The infinite knowledge base from Stackoverflow has an entry about this, but the question is vague as the answers.
Anyone has a better approach?
http://stackoverflow.com/questions/1139102/data-module-in-dll-with-delphi
The infinite knowledge base from Stackoverflow has an entry about this, but the question is vague as the answers.
Anyone has a better approach?
http://stackoverflow.com/questions/1139102/data-module-in-dll-with-delphi
Found another entry http://stackoverflow.com/questions/8435444/delphi-error-in-using-ttable-in-datamodule-in-dll
ReplyDeleteMy applications are divided into multiple BPLs (like dlls) by functionality: Launcher (exe, small about 200kb), Core (data module, some global functions), and follows for ex: Bank.bpl, all documents, reports related to bank functionality. Later it's easy to fix/upgrade just some components.
ReplyDeleteBPLs are good when you deploy even VCL & RTL. I just want to deploy main EXE & DLLs as plugins/addons, nothing more.
ReplyDeletedata module is similar to a "non visual component", you can use non visual components in dll, I hope this answer's your question, in part at least, the other part is, you have to instantiate the data module very early on so that you can make use of it, i.e.:
ReplyDeletelibrary xxx;
uses
yyy
,zzz
, myDataModule in '..\src\myDataModule.pas';
begin // <- entry point
GMyDataModule := TMyDataModule.Create(NIL); // new instance
try
// some other "init" logic
finally
GMyDataModule.Free; // release it
end;
end. // <- exit point
Using cross packaged classes/inheritances, gobal variables it's more easy and convenient bpl way, dlls are more for function/routines exports. Just LoadPackage and Go :)
ReplyDeleteP.S. my bad, don't call GMyDataModule.Free in the finally block, also, you may want to create and free the instance of data module in it's unit's "initialization" and "finalization" sections...
ReplyDeleteInteresting approach, like Delphi IDE, can I mix DLLs and BPLs? Isn't that a pain in the back? Can I LoadPackage from a DLL?
ReplyDeleteI can see more experiments in the near future, and more questions :-D
Thanks for your pointers!
Initialization / finalization it's an ancient approach. From Program/Main unit just load your dll, create an instance of DataModule with Application as Owner. It will be freed automatically on Application.Terminate
ReplyDeleteTake a look: http://edn.embarcadero.com/article/27178
ReplyDeleteThe only thing I don't like is the need to build my app requiring packages. I'll explore the way of DLLs. If there is a DLL Hell, there's no need to have a BPL Hell too. I say that 'cause some of my customers actually have third party apps made with some Borland/CodeGear/Embarcadero tool and I have no interest in colliding with them. I want to have all my stuff under my control and not bothering anyone else.
ReplyDeleteHeinz Toskano if you put the bpl's in the same folder as the exe, you shouldn't have bpl hell, however, I strongly recommend against bpl's and dll's also if you can help it, the only reason to use dll's IMHO is plugins, no other reason...
ReplyDeleteJust place rtl, vcl and related packages in app folder. It's done by installer script. That's all. No more hell.
ReplyDeleteMany thanks for your advices. Anyone who has any other ideas or suggestions is welcome to contribute.
ReplyDeleteI am not sure why you would want to put something like a DataModule (DM) in a DLL. If the app user has to log into a database engine, the best place to do that is in the DM, and that needs to be done very early - perhaps before the Main form comes up.
ReplyDeleteI never use BPLs, and only use DLLs for plugins. If I have a DM shared across multiple projects, I just include the unit in each project. DMs "have the hood up" way too often to be out in DLL-land, not easily edited/compiled/tested. Last, exceptions in DLLs are much more problematic than in the main EXE.
Kevin McCoy Datamodules are a great way to encapsulate functionality. What I would suggest to the original poster is one of the following two approaches:
ReplyDelete1) Use interfaces to the external world: this allows your DLL to be used by any other language supporting interfaces.
2) Use a procedural API to the external world. This requires a bit more work but is also worth its while.
However, please, keep the DataModule well encapsulated in one of the above layers, don't expose it directly.
You can create an instance in DLLAttach(google, there is a bit of stuff) and destroy it in DLLDetatch.
PLEASE DO NOT EXPOSE THE DATAMODULE DIRECTLY, unless you are 101,00000000000% sure nobody else(known and/or unknown, i.e. without you being aware of it!!!) will use it.
Regards,
A
Andrea Raimondi I was thinking about some helpers to interact with the database, the good, I can export helpers, the bad, it's hard to implement, the ugly, there to many tables, views, sp and triggers. Any way still considering to forget about modularity and keep the one exe approach, maybe at a later point, I reevaluate the modularity again, or maybe for the version 2.0 :-D
ReplyDeleteHeinz Toskano I still didn't quite understood why do you need a dll for the db stuff when you can simply share data module unit.
ReplyDeleteModularity and plugins are really good when your project is big. When installing a specific plugin it can adjust DB for specific functionality, integrate itself in interface: menu, toolbars. But it should be right approach, not just for fun, to have data module in dll.
ReplyDeleteThe datamodule can serve as a "capsule" to have your functionality.
ReplyDeleteHowever, there should be a strong discipline when doing this.
Dorin Duminica Sharing DM unit means duplicate code, not good if you have many addons. The main goal is to build a complex ERP, where not all features are deployed to all users. The ability to deploy only the needed modules to certain users, can only be possible using addons or many small/reduced versions of the same ERP, as you can deduce the later must be avoid, again because of code duplicity.
ReplyDelete