When to assembly

Feb 6, 2007

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. Not in price and performance, but in customization.

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.

* Only $4.95/month ASP.NET & Windows 2008 + IIS 7 Hosting! FREE SQL Included

Comments (7) -

Jesper
Jesper
2/7/2007 9:20:42 AM #

That sounds a lot like copy-paste programming to me. What happens, when you use a component in 15 different projects, you've customized it, and then you realize it has one or more errors? Will you remember each project you've used it in?

I agree that it has advantages, but also significant drawbacks.

 zproxy
zproxy
2/7/2007 9:26:59 AM #

What if you could recompile this external dll in a way that all unreferenced classes/methods would be excluded.

Would such a tool satisfy your needs and would you pay a small fee for such a tool?

Smile

Mads Kristensen
Mads Kristensen
2/7/2007 10:18:04 AM #

@Jesper, that's partly what I mean about a distributed library. In that case it makes completely sense to wrap it up in a dll file.

@zproxy, that doesn't sound very smart in to me. Either you want the whole dll or you don't.

 Eber Irigoyen
Eber Irigoyen
2/7/2007 2:13:29 PM #

I've noticed you do that a lot, I particularly don't like your approach, the biggest problem is with one bug in that class, now you have a bug in many different files, and maintaining becomes a nightmare, you have multiple versions of the same thing, etc... definitely a bad practice to teach the new kids, this is one of the basic not-to-do rules for developers

you come up with some really good stuff, I think you just need to improve in your practices

Mads Kristensen
Mads Kristensen
2/7/2007 3:02:10 PM #

Eber, I stongly disagree. If I write a HttpModule for HttpCompression, there is aboslutely no idea in putting it in a dll file. If I had 10 HttpModules then it would make sense, because then it has characteristics of a component. My business and data logic also always resides in a separate assembly because of the strong cohersion of the classes. In the case of a control library, then I build it with distribution in mind.

However, if I in one project need a stock quote class, then I just paste it in. I've done this for years and it works extremely well for me. If you call it bad practice, you would be in your right but I strongly disagree.

The reason why I always write that you just have to paste a certain class into App_Code, then it's because that approach works for beginners and advanced developers. The advanced will know if it is the right way to do it, but the beginners might not. So you can always put the classes I write into your custom assembly if you choose to, but I don't write it because you already know you can (because you're an advanced developer).

 Steve Huntingdon
Steve Huntingdon
2/9/2007 3:40:36 PM #

Seems to me that life would be so much easier (and smarter) with PHP

 uiyuyk
uiyuyk
2/21/2007 2:33:12 PM #

>>Seems to me that life would be so much easier (and smarter) with PHP

you sound like a php coder......

Comments are closed

About the author

Mads Kristensen

Mads Kristensen
Program Manager at the Microsoft Web Platform team and founder of BlogEngine.NET.

More...

Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.