Over the years, I’ve used a lot of third-party components and self built control libraries. It an easy way to add functionality to your code projects – just reference the dll file and that’s it. This encapsulated functionality comes in most cases at a high cost. Imaging that you have an assembly of your homemade ASP.NET controls that you wish to use in your new website. In there you have a custom version of the GridView control that does something smart. On your new website this is exactly what you need, but you need it to behave a little different in a certain situation. You then have to create a new class that inherits from the custom GridView and extend it by overriding a couple of methods. You don’t need any of the other controls in that assembly. Now you are faced with a couple inconveniences. • You reference an entire dll file just to use one class, and • Still have to create an extension class for that control To make the customization easier, you could open the control project and edit the custom GridView and expose the changes as properties instead. That would take some time and testing, just so that one particular website can use the added properties.
Pull it out If you instead pulled the CustomGridView.cs file out of the control library and stuck it into the App_Code folder and customized it directly, you would gain multiple things. • Easier debugging • Less code needed to customize the custom GridView • Reduce the overhead of the referenced dll file This approach is only beneficial if the control doesn’t make use of other classes in the assembly, such as interfaces, base classes and helper classes.
Repository The way I like to keep my self-contained classes is in a code repository, which basically are some folders on my hard drive. Whenever I need one of the classes, I simple copy it into the project and customize it if it needs to be. It’s the same kind of plug ‘n play functionality of the dll files, but in a much smaller scale. This gives me the freedom to select a variety of different functionality out-of-the-box and still keep my project clean from unnecessary dll files. That makes them smaller, more transparent and easier to maintain. Class libraries Sometimes it does make sense to build a class library instead of the loose files. However, there are rules to when this is beneficial. The rules are the ones I code by. It’s better to build a class library when: • The classes in the library are dependant of each other • The library has characteristics of a component • The library has to be distributed separately I might have missed some other rules, but this is basically it. The point is that not all types of classes belong in a library and it’s a good idea to identify them as early as possible to avoid extra work down the line.
Add to 
Bookmark Murdok:
