Where to put generic classes in ASP.NET MVC

Posted on 2015-02-13
Last Modified: 2015-02-16
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 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.
Question by:Newbis
  • 3
  • 2
LVL 28

Expert Comment

ID: 40608315
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

Author Comment

ID: 40608538
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. :)
LVL 28

Accepted Solution

omgang earned 500 total points
ID: 40608658
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

Author Comment

ID: 40608946
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.

Author Closing Comment

ID: 40612359
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.

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article shows how to deploy dynamic backgrounds to computers depending on the aspect ratio of display
When crafting your “Why Us” page, there are a plethora of pitfalls to avoid. Follow these five tips, and you’ll be well on your way to creating an effective page.
The viewer will get a basic understanding of what section 508 compliance can entail, learn about skip navigation links, alt text, transcripts, and font size controls.
Learn how to create flexible layouts using relative units in CSS.  New relative units added in CSS3 include vw(viewports width), vh(viewports height), vmin(minimum of viewports height and width), and vmax (maximum of viewports height and width).

838 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question