Соглашения о присвоении имен - Одно правило для Контроллеров, никакие правила для Моделей и Представлений
Как насчет автоматизации всех рабочих процессов e2e с помощью endly e2e test runner.
Запуск приложения и делегирование тестирования на Cypress может выглядеть следующим образом
@ test.yaml
pipeline:
test:
multiAction: true
startApp:
async: true
action: exec:run
commands:
- npm run serve
runTest:
async: true
action: exec:run
commands:
- wait-on http://localhost:8000 && npm run cypress
2 ответа
Соглашение о контроллере таково, что маршрутизация может легко найти контроллер без дополнительной настройки. Добавление требуемого окончания Контроллера снижает вероятность случайного показа объекта через маршрутизацию MVC.
Существует также встроенное соглашение для Views. По умолчанию представления должны находиться в папке, названной для вашего контроллера, и называться так же, как и вызывающее их действие, это то, что позволяет вызову метода View () в вашем действии работать без указания представления. Я все равно часто задаю себе представление, но если вы ищете соглашение, оно определенно поощряется платформой.
С точки зрения модели, вы правы, стандартного соглашения не существует. Причина этого в том, что платформа ASP.NET MVC никогда напрямую не касается моделей. Требуется соглашение для контроллеров, чтобы найти их из маршрутизации, и соглашение для представлений, чтобы найти их из контроллеров ... но модели доступны только из логики в контроллере, поэтому инфраструктура не должна знать о них ,
При этом я видел, что большинство людей строят свои модели точно так же, как они строили свои сущности или модель предметной области до MVC. Если вы используете активный шаблон записи, назовите модели, соответствующие таблицам, на которые они отображаются; если вы больше фокусируетесь на домене, назовите модели, соответствующие той части домена, которую они моделируют. Кроме того, я видел, как все больше и больше людей создают набор моделей представлений, которые просто используются для представления данных в пользовательском интерфейсе и создаются путем извлечения деталей из различных моделей в вашем домене.
Это просто соглашение, а не требование! Вы можете изменить это поведение, настроив DefaultControllerFactory или создав собственную фабрику контроллеров.
см. здесь для получения дополнительной информации. Также есть несколько примеров в проекте MvcContrib, которые внедряют контроллер из движка Dependency Injection. проверить это здесь .