Is there a problem in separating my Code to more than one Dll File
Ex:
Dll For Printing and it's action
Dll For Logs file
Dll For Fitting
Dll for other work
or the best make all this operations in one dll file
i believe this depends on a couple things.
what's prompting you to split the procedures up into separate .dll files?
are you finding the code to be unmanageable in one .dll file?
are you looking to re-use the .dll files by multiple plug-ins?
Splitting applications into multiple DLLs has a slight performance overhead, but unless all of the DLLs are very large, it isn't really noticable.
If you have several applications that share a common code base, then it makes sense to put the shared common code into a seperate assembly so that each application that uses it does not have to replicate the code.
Logical splitting may make sense if everything isn't needed right away, or at all during some sessions, in which case demand-loading can be implemented. E.g. if you had a custom batch plot as part of a larger drawing manager application it might make more sense to split it out and load it when called for instead of every time. It can also make for easier debugging and updates if there isn't a lot of reliance on each other. Multiple files require a little more management in making sure they get loaded, copied, updated etc. as opposed to a single file where its either done or not.
@dgorsman wrote:Logical splitting may make sense if everything isn't needed right away, or at all during some sessions, in which case demand-loading can be implemented. E.g. if you had a custom batch plot as part of a larger drawing manager application it might make more sense to split it out and load it when called for instead of every time.
Splitting an assembly up into multiple assemblies for the reason you cite above, serves no purpose, and is pointless.
In a just-in-time compiled execution environment, every method in an assembly is "demand-loaded". Or, put more simply, the runtime does not load and compile methods and their code unless and until they are actually used. If a method is never called in a session, it is never loaded or compiled (this doesn't apply to assemblies that are pre-compiled using ngen.exe).
So, in fact, there really is no purpose served by splitting an assembly up because parts of it may never be needed in a session, so that each of the component parts can be 'demand-loaded', because every method in an assembly is already being demand-loaded. In fact, breaking up assemblies for that purpose alone can partially-defeat the purpose of just-in-time compilation, because each assembly has a fixed amount of overhead, regardless of its size.
Most of the legitimate reasons that determine how a code base is laid out, have to do with dependencies on other code or libraries that may not always be present (e.g., RealDwg has no AcMgd.dll), or because the developer is following best practices and maintaining separation between various functional layers (e.g, separating UI from business logic).
Can't find what you're looking for? Ask the community or share your knowledge.