Where to put generic classes in ASP.NET MVC

I know similar questions have been asked on various forums, but I want to ask this a little more specifically:

When writing an ASP.NET MVC application, what's the best practice for where to include classes that don't strictly fit into the MVC model?

In my understanding, the view plays a similar role to the ASPX page in WebForms, except of course with special routing logic, etc.  The controller plays a similar role to the code-behind page...that is, there's built-in logic that connects controllers to page requests (e.g., that causes the controller to execute following a given URL request).  And the model is supposed to play the role of classes that expose data from the database or other data source....so whereas in an old-fashioned application, people would create maybe a "person" object and a "company" object, and whatever, with properties read from the database, now these classes all go in the model.

The issue is that typically, there are always going to be classes that don't correspond to a page request or to a database object.  For example, maybe there's a singleton class to handle errors and logging, or maybe there's one to store certain constant values, or one to get certain things from appSettings that are used a lot in the application, or maybe one that processes some specific business logic that really isn't linked to a page request, as it could possibly be called through several different paths.

In reading various forums, I've seen a few different viewpoints:
(1) Put these into a separate libraries (e.g., different projects), so they're compiled in their own dll files.
(2) Just throw these into the model anyway, even if they don't really fit (or maybe just sort of fit in that they have properties which could be classified as "data").
(3) If a class's main use is as a "verb" rather than a "noun," then try to fit it into the controller paradigm, even though it doesn't fit there either.
(4) Create a new folder and namespace, and call it something.

As to (1), I see that could work well for utility functions that one may want to include in multiple projects.  But in other situations, it may create too many dependencies back to the main project, passing lots of data through parameters, doing callbacks, and basically making things over-complicated.

(2) seems reasonable to me.  But I'm still wondering if maybe it's abusing the model folder/namespace too much.
(3) seems way off, because the controller logic is very particular, so it doesn't seem appropriate for generic classes.
(4) seems reasonable, but it's kind of like admitting that MVC is broken in some way and needs one to add to it.  Plus, it means that people need to look into more folders to find where the code is.

In any case, just wondered people's opinions about this.  I know there's maybe no single clear answer, but I'm trying to understand better what's ideal for this kind of situation.
Who is Participating?
omgangConnect With a Mentor IT ManagerCommented:
Actually, I named the folder Extensions and use it for my extension methods because I, too, searched around the internet during development and found suggestions to do it this way.  My research suggested option 1 or option 4 as preferred.  The MVC paradigm really pushes for keeping the models, controllers and views clean and specific which, in my opinion, is why #1 and #4 are preferred over the other two.  As for concerns regarding people having to look in other folders for the coding, consider that, in my case, I'm the only developer and specifically set the project up with separate folder(s) for this.  In a team environment, wouldn't these decisions be made by the team at the beginning of the project so everyone knew where to expect to find specific types of code?  I think the important thing is consistency, at least within the project.

OM Gang
omgangIT ManagerCommented:
Not sure if I have a valuable opinion as I'm pretty new to MVC.  I just recently developed my first MVC project (MVC 5) and went with option 4.  I created a separate Extensions folder and have utility methods in a namespace there.  It made the most sense to me.

OM Gang
NewbisAuthor Commented:
Thanks for the response.  That makes a lot of sense.  But it makes me wonder if there's any standardization out there for what to call it.  You call yours Extensions.  Someone else might create a folder called Extensions to store extension methods, and maybe their regular classes would go in a Classes folder, or something else.  I guess outside of those things that fit the MVC paradigm, it's kind of a free-for-all....which is okay, I'm just wondering if I'm missing something. :)
NewbisAuthor Commented:
Yeah, makes sense.  Maybe I'm too hung up on the idea of MVC standardizing your folders for you.  I guess it just makes sense to create my own folder and put it in that.
NewbisAuthor Commented:
So I ended up creating a Classes folder & namespace for all classes that are unlikely to ever be used as models for views.  The idea of implementing everything as extension methods is interesting, and I've read that suggestion too.  However, it doesn't completely make sense to me, as extension methods are a solution to a specific problem, so while one could create extension methods on a high-level object to add certain public utility functions to all its children, it seems that if I really want to create new objects, then they should just be regular classes.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.