Do you store your helper classes in a separate assembly?

Question

I just want to know if anyone stores their helper classes or methods in a separate assembly and why...just for clean management of them? I've seen so many posts about using a helper folder inside your MVC project and that brings me back to the messy old days in ASP.NET where people were using an App_code folder instead of cleanly separating things out physically like this into its own project.

And likewise nobody doing real architecture is going to put models in some folder in your MVC web assembly. They would go in MyApp.DataLayer assembly or MyApp.Models or something like this.

Answer 1

Yes, but for reasons, which are common to other assemblies as well

• Becomes easy to plug into any other project.(might need some editions).
• Reusable
• Easy to improve
• Easy to refractor
• As not part of a project, but project itself, it is easy to document and easy for developers to understand
• Clears out some of the mess

But for all that above, your assembly, when ready, should be a "job well done", other wise, it is better to keep the helper classes to where they belong.

Answer 2

We have some helpers in a separate project and some in the web project. I think you'll find that some of your helpers need to use abstractions that you've defined in your web project itself. And that will often force you to put those helpers into the web project, because it's not likely desirable to have some other project that has a reference to the web project. I don't consider it the same as using App_Code. These are files that are compiled at compile time inside your IDE, with no special "magic" that gets applied to App_Code.

Answer 3

I use projects to separate out the different layers in my web or form apps. It allows me to respect the business rules better. Also I find it easier to track down where I need to go if I want to make a change.

But I have seen people use folders that label the layers in the solution but I think that is a little messy.