将代码从主应用程序拆分到单独的库是否会增加成本？
我可以理解在应用程序启动时加载单独的 DLL 会增加成本，但是在单独的库中引用代码时是否会产生开销？
假设我有我的应用程序（无论是 ASP.NET WebForms、MVC 还是 WinForms），出于某种原因，我决定从维护的角度来看，最好将几个类移出到它们自己的单独库中，以便我可以稍后将其他应用程序浮动在其之上。
与将它们保留在主应用程序中并在那里引用它们相比，引用独立库中的类是否会增加开销？我想将它们移出，但应用程序可能需要大量缩放，因此我不想这样做搬起石头砸自己的脚。
通常情况下，我会毫不犹豫地将代码移至它自己的库中，但通常我不会编写需要此级别所需扩展级别的应用程序，因此我现在正在重新猜测自己。
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 move 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果从 API 设计/代码清晰度/维护的角度来看有意义——那就去做吧！
更快的处理器比必须维护大泥球的程序员便宜。
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.
加载程序集会产生开销，因此将类型移动到新程序集会带来延迟。如果加载很多个程序集会影响性能，但根据我的经验，这并不是一个大问题。
请记住，如果您使用多个应用程序域，则有两种加载程序集的选项：每个应用程序域或域中立（即在应用程序域之间共享）。如果您在多个 AppDomain 中加载相同的程序集，则必须支付多次加载的成本（并且在此过程中您还将拥有程序集的多个副本，这反过来也可能会影响整体性能）。
另一方面，通过将有用的类型移至程序集，您很可能可以更轻松地在其他项目中重用这些类型。
根据我的经验，存在可测量的开销，但除非您确定这是您遇到的任何性能相关问题的主要根源，否则我不会管它。程序集应该主要在架构级别上有意义。
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.
总的来说，单独程序集的最大开销是构建时间：Visual Studio/Resharper 组合在少量（< 15）程序集时效果最佳。
使用命名空间构建代码。使用程序集组织您的部署。
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.
虽然我没有任何统计数据来支持它，但我不相信对于用户级应用程序（您确实提到了 winforms），您不会通过将某些类分离到不同的程序集中而注意到任何真正的性能下降。您可能会将大部分时间花在 UI/Web 服务器/数据库领域。 。 。如果没有“感觉上”的差异，那么我会将不经常使用的类移动到单独的程序集中，并仅在需要时动态加载它们。您可以从 app.config 条目驱动此延迟加载，以获得最大的灵活性。就我个人而言，除非您需要构建高度可用或可扩展的应用程序，否则我不会为多域应用程序模型而烦恼。我可以向你保证，这不是一件小事！
博学的穴居人
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