Is there an added cost of splitting code out to a separate library from your main application?_问答_开发者

I can understand an added cost at application startup of loading a separate DLL, but is there an overhead when referencing code in a separate library?

Say I have my application (be it ASP.NET WebForms, MVC or WinForms) and I decide for one reason or another that from a maintenance standpoint, it's better to have a couple of classes moved out to their own separate library so that I can float other applications on top of it some time down the road.

Is there any increased overhead in referencing the classes in the separated library than if I'd kept them inside my main application and referenced them there? I want to move them out, but the application has a potential requirement for a huge amount of scaling, so I don't want to shoot myself in the foot by doing this.

Normally I would mo开发者_C百科ve the code out to it's own library without giving it a second thought, but usually I'm not writing applications that need the level of scaling required for this one and so I'm now second guessing myself.

If it makes sense from an API design / code clarity / maintenance point of view -- do it!

A faster processor is cheaper than a programmer who has to maintain a Big Ball of Mud.

If there's any overhead at all, it negligible (measured in nanoseconds).

In any case, scalability is not about squeezing out a few more nanoseconds here and there, but about whether you can handle an increase in application load by adding more machines (horizontal scalability) or more hardware (vertical scalability).

Do make your separate library - it will have no measurable impact on performance or scalability, but it will hopefully make the code more maintainable.

There's an overhead for loading assemblies, so by moving types to new assemblies you introduce a delay. If you load many assemblies if will affect performance, but otherwise it is not a big problem in my experience.

Keep in mind that if you're using multiple AppDomains, there are two options for loading assemblies: Per AppDomain or domain neutral (i.e. shared between the AppDomains). If you load the same assemblies in several AppDomains you will have to pay the cost of loading these multiple times (and you will also have multiple copies of the assemblies in the process which in turn may also affect overall performance).

On the other hand, by moving useful types to assemblies you most likely make it easier to reuse those in other projects.

In my experience there is a measurable overhead, but unless you're sure this is the main source of any performance related issues your experiencing I would leave it alone. Assemblies should primarily make sense on the architectural level.

The only penalty you pay is the load time of that library whenever it is first used. Other than that, you don't need to worry about a performance penalty for splitting it out into another library. All libraries will get loaded into the same application domain by default. If you load them into different domains then you will experience some performance decrease when going across domains.

Overall the biggest overhead with separate assemblies is the build time: the Visual Studio/Resharper combination works best with a small (< 15) number of assemblies.

Structure your code using namespaces. Organise your deployment using assemblies.

Although I don't have any stats to back it up, I don't believe that for user level applications(you did mention winforms) you'll notice any real performance degradation by separating some of your classes into different assemblies. You will probably spend most of your time in UI/web server/database land . . . If there not a 'feel-able' difference, then I'd move classes that are not used very often into separate assemblies and dynamically load them only when needed. You could drive this lazy load from app.config entries for maximum flexibility. Personally, I wouldn't bother with multiple-domain application models unless you needed to build a highly available or extensible application. This is no small undertaking, I can assure you! TheEruditeTroglodyte