You need to create a dll in C # with the number of functions 200 or more, divided into groups according to functionality.

Questions:

  1. Does it make sense to create such a large dll (groups are divided into classes for convenience) or is it better to create your own dll for each group?

  2. What criteria to focus on when splitting into dll?

  3. What are the pros and cons of a split?

If possible, then in more detail, with an explanation.

  • four
    The question has no solution in its current form. By itself, the number of 200 functions - this is normal, sometimes more. But it is impossible to make such decisions based on the number of functions alone. The best way to organize the code depends on the task that it solves — and you didn’t call it. - Pavel Mayorov
  • 2
    Well, the point of minus-close? A normal question, albeit somewhat common. You can answer it normally. For novice programmers, such things are not obvious, because there are not one or two factors. - Athari

1 answer 1

It makes sense to break into different dynamic libraries if you really need it. Possible reasons:

  • Different applications will use different libraries , so it may be irrational to connect to each monstrous library. The larger the library, the longer JIT takes, the slower the download, etc.

    • For example, if you ship a library using NuGet, then size does matter, especially if you ship versions for different versions of .NET, which also has a noticeable effect on size.

    • On the other hand, in some thick application it is not so important, because a thick installer will not download through a thin channel, the installer can drive JIT away during installation, etc.

  • The division into libraries and the explicit indication of the dependencies between them makes developers more carefully follow the separation of code . If an application is developed by a large team of different degrees of professionalism, then it may be convenient to scatter the logical models physically.

    • For example, when implementing the MVVM pattern, explicitly allocate the View into a separate assembly so that no one dares to add dependencies between View and Model.

    • On the other hand, if the application is small and is developed by one or two developers, then the benefits of such a division will be small, because one developer can keep all the architecture in his head.

  • If libraries have different dependencies, then libraries can be divided by dependencies .

    • For example, if one part of the code depends on SQLite, the other requires Autofac, and the third works on the same .NET framework, it is reasonable to split the library into parts so that applications dependent on the library are not forced to drag databases and NuGet packages with them. are needed.

    • On the other hand, if dependencies differ only in assemblies from the framework itself, for example, System.Xml and System.Net, then there will be no practical benefit from the division, because these assemblies are available to everyone, everywhere and immediately.

Do not forget about the cons:

  • If the library is one, then it compiles and builds faster . One library per 100 classes will assemble faster than 10 libraries per 10 classes each.

  • It is easier to connect one library than ten, and resolve dependencies between them and with external dependencies.

PS 200 functions are very few.

  • Thank you, everything is very clear. - Andrei
  • And how then can the functions in one library be divided into subgroups (for the convenience of calling from an application)? - Andrei
  • @Andrey From the point of view of files, you can break the code into a hierarchy of folders in a project according to some logical parts. For example, in the case of using OOP, it can be broken down into class hierarchies, separated by interop, grouped by purpose and functionality. / In terms of code classes can be divided into namespaces (namespace). Visual Studio generates namespaces by folders, but this is not always rational, because namespaces can be a bit much, and for the calling code this can be inconvenient. - Athari
  • @Andrey In general, there are many factors, depending on preferences. Do not bother your head with organizing code for projects, folders and namespaces - this is not its main quality. Over time, figure it out for yourself and determine your preferences. - Athari
  • run JIT on install Perhaps you meant NGEN, not JIT. - PetSerAl