#angular
#angular
Вопрос:
Документация Angular и Angular CLI подталкивают новичка Angular (я в этой лодке) к реализации маршрутизации приложений в отдельном модуле от основного приложения, не объясняя, почему к нему применяется этот особый подход. Например, когда я создаю новый проект Angular с маршрутизацией с использованием CLI, я получаю app-routing.module.ts файл при импорте в мой основной app.module.ts файл.
Я прочитал, что это из-за разделения проблем, но мне трудно принять это как основную причину, потому что в приложении есть несколько проблем, но только маршрутизация получает свой собственный модуль.
Как новичок в Angular, я понятия не имею, является ли это вопросом, основанным на мнении, или есть законная техническая причина, по которой это хорошая идея. Я не могу найти какую-либо информацию так или иначе, вот почему я спрашиваю.
Для тех ветеранов Angular, которые работали над приложениями среднего размера, когда вы помещаете или не помещаете маршрутизацию приложений в отдельный модуль и почему? Становится ли это технически необходимым в определенный момент или это просто организационное соглашение?
Спасибо.
Комментарии:
1.Многие люди не понимают голосования и принятия или почему они важны 😉 Если вы спрашиваете конкретно о том, почему
app-routing.module.tsсуществует, и почему его нужно реализовать как отдельный модуль — это не так. Во многих моих проектах просто естьappapp-routes.ts. Он импортирует{ Routes, RouterModule } from '@angular/router';, но у него нет своего собственного@NgModule({...});.2. теперь он снова открыт 🙂 Я полагаю, что это ваш вопрос, касающийся автоматически сгенерированного модуля «app-routing.module.ts»:
When do you put or not put your application routing in a separate module, and why? Does it become technically necessary at a certain point, or is this simply a organizational convention?мой голос — «организационное соглашение»… но я готов ошибаться 😉
Ответ №1:
Все дело в разделении проблем. Хотя у вас может возникнуть соблазн поместить всю логику приложения в один модуль, обычно рекомендуется разделить каждую проблему на отдельный модуль. Модуль, определяющий представления, отображающие информацию о продукте, не должен напрямую беспокоиться о том, как и когда отображаются его представления. Отделение разных логических областей друг от друга сделает ваш код более чистым и удобным в обслуживании.
Комментарии:
1. Спасибо за ваш ansewr EmmBee. Я понимаю принцип разделения проблем, но у меня остается ощущение, что это не может быть полным ответом. Например, я бы сказал, что службы приложения — это другая проблема, чем представление, но они не получают свой собственный модуль, как маршрутизация. Или я что-то упускаю? Может быть, причина в том, что маршруты определены в их собственном модуле, потому что угловые маршруты потенциально могут охватывать / указывать на несколько модулей?
2. Сервисы должны быть отдельными единицами. Эти «блоки» просто не являются угловым «модулем». Вот хорошее определение :
a module is a mechanism to group components, directives, pipes and services that are related, in such a way that can be combined with other modules to create an application. An Angular application can be thought of as a puzzle where each piece (or each module) is needed to be able to see the full picture.: angular-2-training-book.rangle.io/modules/introduction