views:

120

answers:

5

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.

+2  A: 

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.

Charlie Flowers
I don't mean same as App_Code literally I mean just the concept of putting anything that should be in a separate assembly in reality in some sub folder in your web application which to me is armature.
CoffeeAddict
I understand. My first inclination was to put them in a separate assembly too. But that was misguided. The first time I needed to make an HTML helper that used a class that was in my web project, I realized that, at least for my situation, and probably for many situations, the helpers best belong in the web project.
Charlie Flowers
+1  A: 

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.

JPJedi
+3  A: 

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.

Asad Butt
I'm more or less talking about those helpers specific to only a certain project. I still think separating them out physically just makes it much easier to find things (discover-ability) and a much more professional way to maintain and to reduce clutter in your web app.
CoffeeAddict
Not all helpers you create are going to be reusable across any mvc project.
CoffeeAddict
+1  A: 

Yes, because they are part of the Business Layer. Two big payoffs:

  • Reusability
  • Testability

Keep in mind that your utility functions and helper classes are likely to be some of the most heavily used components of your entire system. Without full BICEP testing, you run a truly unacceptable risk.

Mark Brittingham
A: 

Most helpers that I create are usually layer specific so I tend to keep them with the assembly the base assembly that needs them. I don't see a reason to add in another project to store a large number of specific helper classes.

Andrew Smith