.net - Are applications with many DLLs a bad thing? -
We have an entry web application that included 4 compiled components (DLLs). A year ago, we started implementing more granular components in an effort to reduce functionality, reduce coupling and reducing the risk of reconstructing and deploying a large part of the code. Although no one argues that this approach has given us much improved resilience and speed in the market, adding new functionality and patching bugs, but now it includes about 40 DLSs. We have a naming convention that works well to identify our components.
My question is: Is there a dual-side (performance, maintenance, etc ...) to make an application with many DLSs?
Editing: We are searching for the option of refactoring code in large components, which I think can be a kind of regression ...
My question is: Is there a downside (display, maintenance, etc ...) to make an application with many DLSs? A negative side with many DLLs? No - Is there a downside with many DLLs? Sure. So much is it? An assembly is a medium of organization, such as namespace and classes. Nameshah defines logical boundaries, assembles physical boundaries. You should try to keep the assemblies consistent, and see them as a system module. And of course, a small demonstration problem if you have hundreds but with 40, I do not see any problem.
Comments
Post a Comment