Какой лучший способ изменить способ создания областей в Razor MVC?

Я перехожу к использованию областей в проекте

Я делаю что-то подобное в течение нескольких месяцев, но, начиная со старого проекта WebForms, добавляя компоненты MVC через функцию VS 2013 Add → New Scaffolded Item..., чтобы использовать структуру MVC и маршрутизацию на стороне сервера, Я также использовал WebAPI и SignalR на стороне сервера. Я определенно все еще новичок, но, возможно, немного дальше в подобном процессе, вот некоторые из моих мыслей и вопросов о том, чего вы хотите достичь:

---

• Удаление одной из созданных папок
• Небольшое изменение файла web.config
• Добавление нового файла или двух с некоторыми значениями по умолчанию

В какой среде вы развиваетесь? Например, если вы используете леса VS 2013, вы, скорее всего, можете изменить шаблоны T4, чтобы предотвратить или перенаправить создание папок, классов и т.д. Здесь размещена адресация, где вы можете найти эти шаблоны, и вот лишь один из многих понятий для T4. Путь к шаблонам на вашем компьютере будет зависеть от версии VS. Изменяя или создавая новые шаблоны, вы должны иметь возможность сделать все 3 очка выше относительно легко. Если вы работаете в такой среде, я попытаюсь подробно рассказать о том, как вы могли бы изменить модификацию шаблонов (возможно, у вас уже много сообщений, на которые вы могли бы ссылаться, хотя бы лучше).

---

• Несколько изменений в файле AreaRegistration

Если вы работаете с MVC 5 или позже, я бы рекомендовал использовать маршрутизацию атрибутов. Это кажется более стандартным при работе в рамках парадигмы API (наследующей от ApiController вместо Controller), но я нашел распространение этого на традиционные контроллеры MVC очень полезным.

Предполагая MVC 5, я рекомендовал бы модифицировать AppStart\RouteConfig.cs RegisterRoutes(), чтобы включить маршрутизацию атрибутов, а затем добавить весь маршрут, такой как:

routes.MapMvcAttributeRoutes();

routes.MapRoute(
    "NotFound",
    "{*url}",
    new {
        controller = "Error",
        action = "Index"
    });

В этот момент я удалю файлы xAreaRegistration.cs и удалю вызов RegisterAllAreas() из Global.asax, но вам не нужно заходить так далеко. Затем я украшаю классы своих контроллеров (где бы они ни жили) и их методы с атрибутами по мере необходимости. Используя маршрутизацию атрибутов, я смог освободиться от традиционных соглашений MVC. Я все еще могу вернуться к ним, но я могу разместить контроллеры в любом месте своего проекта и легко определить маршруты своих действий.

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

---

Вот простой пример того, как это на самом деле переводит из URI в вызов метода:

Если бы я имел Controller ctl с действием act, логически в Area ar, URI, являющийся http://localhost/ar/ctl/a/1, был бы перенаправлен на MyControllerNameDoesNotMatter.Index(1) ниже, используя атрибут украшения, такой как:

[RouteArea("ar")]
[RoutePrefix("ctl")]
public class MyControllerNameDoesNotMatter : Controller {
    ...        
    [Route("a/{optionalParamDefaultsToNegativeOne=-1}")]
    public ActionResult Index(int optionalParamDefaultsToNegativeOne) {
        ...
    }
}

Этот способ просмотра Area более логичен, чем физический, MyControllerNameDoesNotMatter.cs файл MyControllerNameDoesNotMatter.cs не обязательно должен находиться в папке Area\ar\Controllers. С момента принятия этого я фактически отклонился от использования строительных лесов Area, за исключением того, что выкладывать модули приложений на очень высоком уровне - подумайте о суб-приложении, которое может быть автономным SPA.

Я попытался создать атрибут "all-all" route и удалить его из RouteConfig.cs, но я не смог сделать это успешно. Проблема заключается в приоритете маршрута. Он отлично работает как уловка для недействительных маршрутов. Но для действительного маршрута несколько (2) маршрутов заканчиваются, потому что два маршрута атрибута имеют тот же порядок приоритета. Принимая во внимание, что с определением catch-all, определенным в RouteConfig.cs, после регистрации всех маршрутов атрибутов маршрут атрибута имеет приоритет. Я нашел смешанные ответы, которые пытаются решить эту проблему. Кажется, в какой-то момент был параметр Number или Order для атрибута Route, но мне не повезло с этим. Это, по-видимому, нерешенная проблема. Только один из многих вопросов SO, которые остались без ответа.

Отредактировано для учета тега mvc4

Я не видел тег mvc4 перед публикацией. Доступны пакеты nuget, которые достигнут той же функциональности, такой как строительные леса и маршрутизация атрибутов для более ранних версий MVC.