tags:

views:

55

answers:

1

A bit of a silly question, but if I want to create a custom class that's not a controller or model, where should I put it. In WebForms, I stored all my classes in the App_Code folder, but it seems like classes aren't stored there in MVC.

Does it even matter?

+4  A: 

There are plenty of options. Some people just create new folders in the ASP.NET MVC project. Others (including myself) create entirely new projects.

One method I'm rather pleased with is to break up your projects by purpose...

  • MyApp.Core <- All business logic, no DB / Web stuff
  • MyApp.Infrastructure <- DB / smtp / event log
  • MyApp.UI.Web <- the ASP.NET MVC project
  • MyApp.Tests

I've also seen these...

  • MyApp.ApplicationServices
  • MyApp.UI.Controllers

I would suggest taking a peek at all of the various ASP.NET MVC projects out there in open source world to see how they arrange their projects (Code Camp Server, Store Front, Sharp Architecture, Nerd Dinner 2, and plenty of others). I think it will open you up to a world of new possibilities (inversion of control, repository pattern, etc.). That said, it's challenging and I would equate it to the blue pill / red pill scenario.

EDIT: To answer your other question...

I would say it matters but only in the sense that breaking everything up into layers helps you achieve loose coupling. If you keep everything in one project you will be tempted to blur the lines between presentation, business, and database. But if you split everything up and you are cognizant of your project references, the lack of coupling will be much more apparent and you will be much more likely to achieve separation of concerns (SoC). SoC opens the door for unit testing and easier maintenance.

Mayo
SoC != Physical File Location
jfar
Physical File Location facilitates SoC
Mayo