Where shall I put my utilities classes in a ASP.NET MVC3 application?

Question

I am developing a web application in ASP.NET MVC3 with C# and Razor.

I need to create an utility class where I put functions to convert string into dates(years, months, days, etc...).

In ASP.NET Web Forms I used to place this kind of classes inside the App_Code folder. In MVC there is not such folder and I don't think utility classes belong neither to Models nor to Helpers(a folder I created to put my extensions on HTML Helpers).

I read that is a good practice to place the utility classes in a different assembly. I guess a different project should do the job but what kind of project shall I create? A plain Class Library project seem the most logical choice to me.

However in my case I just need to put one single class with several methods so, if we ignore re-usability, isn't it more logic to put the utility class somewhere in my MVC3 Web application?

Answer 1

You should not have utility classes. Convert them to extension methods which is somewhat better. View models are even better.

I usually create a folder called "HtmlHelpers" or "Infrastructure" for plumbing.

A "Common" folder is like the trashcan imho. You put all the junk in it.

Update

I would place it in an extension method for DateTime (placed in a class called DateTimeExtensions which is placed in a namespace called Infrastructure).

And I would use it internally in the view model or when generating the view model (in the controller).

As for which project, it doesn't really matter. What's important is that you got small classes with specific tasks (or responsibilities).

Some argue that you should have several class libraries with distinct responsibilities. I don't do that. I create one UI project and one project for the business logic. However, I make sure that the classes implement one or more interfaces to be able to refactor the application later on. KISS should also apply to project structure and not just the code in them.

In other words: I would put my helpers in the Core (business logic project) in a namespace called Infrastructure.