ASP.NET MVC - поместить контроллер и связанные представления в одну папку?

Question

В настоящее время мы используем структуру папок по умолчанию для нашего приложения MVC, и нам было интересно, можно ли вместо этого поместить контроллер и связанные с ним представления в одну и ту же папку.

Например, подмножество нашей текущей структуры:

 Model folder
   OrderViewModel.cs
 Views folder
   OrderView.aspx
   OrderGrid.ascx
   OrderHeader.ascx
 Controllers folder
   OrderController.cs

Желаемая:

 Order folder
   OrderController.cs       
   OrderGrid.ascx
   OrderHeader.ascx
   OrderViewModel.cs
   OrderView.aspx

У нас есть сотни действий / представлений, и в настоящее время они сгруппированы в слишком мало контроллеров. Это отчасти потому, что становится трудной навигация по проекту при переключении между представлением и связанными с ним классами. Вышеупомянутое решение позволило бы разработчику сосредоточиться на одном действии контроллера, чтобы все они были легко доступны.

Полагаю, что Области могли бы помочь с этим тоже, но нам пришлось бы сделать ~ 100 областей (по одной на набор тесно связанных экранов), чтобы сделать это полезным из POV моей команды.

Answer 1

Фабрика контроллера по умолчанию использует отражение, чтобы найти все классы, производные от Controller, поэтому независимо от того, в какую папку вы их поместите, до тех пор, пока они являются общедоступными и получены из Controller, он будет работать. Но ИМХО смешивать представления и контроллеры в одну папку не очень хорошая идея. Если это вопрос организации ваших контроллеров, почему бы не создать подпапки в папке Controllers?

Answer 2

Я не уверен, что отклонение от соглашения - это хорошая идея, поскольку люди, вероятно, привыкли к стандартному макету папки - но я чувствую вашу боль.

Навигация между файлами была бы менее болезненной, если бы в Visual Studio было еще несколько функций, обнаруженных в IntelliJ IDEA .

Дело в том, что практически любая структура папок со временем будет ухудшаться, так как в проект добавляется больше файлов, а более эффективные инструменты обычно являются более эффективным решением проблемы.

Честно говоря, похоже, что VS2010 начинает принимать некоторые идеи IntelliJ, поэтому, возможно, ситуация улучшится, но до того, как Microsoft догонит, предстоит пройти долгий путь.

РЕДАКТИРОВАТЬ: я забыл упомянуть, что есть плагин , который предоставляет гораздо больше функций для Visual Studio - в значительной степени подняв его на тот же уровень, что и IntelliJ