与许多的Dll A＆QUOT应用;坏事＆QUOT？; [英] Are applications with many Dlls a "bad thing?"

问题描述

我们有一个enterpise Web应用程序，并包含4编译组件（动态链接库）。在一年前，我们就开始试图隔离功能，减少耦合，降低重新编译和部署的code大量大块的风险实施更为精细的部件。虽然没有人认为，这种做法给了我们很大的提高灵活性和速度，以市场增加新的功能和修补的错误时，该应用程序现在包括近40个的DLL。我们有一个命名约定可以很好地用于识别我们的组件。

我的问题是：是否有任何不利的方面（性能，维护，等...），以具有许多DLL的应用程序

编辑：我们正在探索的重构code选项进入，我认为可能是各种各样的回归更大的组件......

解决方案

  

我的问题是：是否有任何   下侧（性能，维护，   等...），以具有与应用程序   许多的dll？

有许多DLL的一个缺点？没有
有太多的DLL的一个缺点？当然可以。

那么有多少是太多了？

这是组件是组织的一个手段，比如命名空间和类。命名空间定义逻辑边界，组件物理边界。

您应该尽量保持一致的组件，并把它视为系统模块。

是的，会有一个（小）的性能问题，如果你有数百人。但是，随着40，我没有看到一个问题。

We have an enterpise web application that did consist of 4 compiled components(dlls). Over a year ago, we began implementing more granular components in an attempt to isolate functionality, reduce coupling and reduce the risk of recompiling and deploying massive chunks of code. While no one argues that this approach has given us MUCH improved flexibility and speed to market when adding new functionality and patching bugs, the applications now consists of nearly 40 dlls. We have a naming convention that works well for identifying our components.

My question is: Is there any down-side(Performance, maintenance, etc...) to having an application with many dlls?

Edit: We are exploring the option of refactoring code into larger components which I think might be a regression of sorts...

解决方案

My question is: Is there any down-side(Performance, maintenance, etc...) to having an application with many dlls?

A downside with many DLLs ? No
A downside with too many DLLs ? Sure.

So how many is too much?

An assembly is an means of organization, like namespaces and classes. Namespaces define logical boundaries, assemblies physical boundaries.

You should try to keep assemblies coherent, and view them as system modules.

And yes, there would be a (small) performance problem if you had hundreds of them. But with 40, I don't see a problem.

这篇关于与许多的Dll A＆QUOT应用;坏事＆QUOT？;的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！