В чем преимущество использования нескольких модулей в angular?

Ответ 1

1.Когда подходить к такому способу расщепляющих модулей?

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

2.Как это полезно?

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

Еще одна причина отделить ваше приложение от модулей - это производительность. Сейчас я работаю над приложением (веб-магазином), которое состоит из 2 основных разделов: один раздел (приложение) для обычных пользователей/покупателей/продавцов и другое приложение для администратора. Теперь пользователям приложения нужны некоторые скрипты/библиотеки, которых нет в приложении администратора, и наоборот. Например, приложение admin использует сетку кендо, для которой требуется kendo.all.min.js script, который при минитировании равен 1.7MB! Теперь было бы разумно заставить всех посетителей сайта загружать тяжелый 1,7 МБ script?

3. Это влияет на маршрутизацию [routeProvider/stateProvider] (поскольку модули определены по-разному, я могу разместить поставщика маршрутов или поставщика услуг для каждого отдельно)

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

4.Если я добавляю зависимость в под-модулях, они по умолчанию вводятся в основные модули?

Да. Если вы введете зависимость X в модуль A, а модуль A будет использоваться другим модулем B, то B также наследует зависимость X.

Ответ 2

Модуль - это ядро ​​функциональности для приложений Angular. Модули содержат весь код, который мы пишите для нашего конкретного приложения и, таким образом, склонны расти огромным монолитным способом. Хотя эта тенденция isnt bad (модули - отличный способ уменьшить глобальный шум), мы можем разделить наши модули.

Существует несколько разных мнений о том, когда создавать модуль и когда устанавливать функциональность в глобальном модуле. Оба следующих метода являются действительными способами разбить нашу функциональность на модули:

1. Когда нужно подойти к такому способу разделения модулей?

Если вы хотите упорядочить свою логику приложений по функциональности или по маршрутам, необходимо, потому что, поскольку ваш код разделен на модули, он легко понимает, тестирует и т.д. Angular реализация модульной системы шаблона модуля.

Модули являются неотъемлемой частью любой надежной архитектуры приложений и, как правило, помогают в обеспечении четкого разделения и организации блоков кода для проекта.

2.Как это полезно?

Для начала, это намного более чистое для разработчиков, исходящее из объектно-ориентированного фона, чем идея истинной инкапсуляции, по крайней мере, с точки зрения JavaScript.

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

  • Разработчик просачивается через структуру каталогов и четко определяет все контроллеры, модели и сервисы. К сожалению, он ничего не говорит ему о том, какие объекты связаны или имеют зависимости друг от друга.

  • Если в какой-то момент разработчик хочет повторно использовать часть кода, ему нужно собирать файлы из нескольких папок и всегда будет забывать код из другой папки где-то еще.

3. Это влияет на маршрутизацию [routeProvider/stateProvider] (поскольку модули определены по-разному, я могу разместить поставщика маршрутов или поставщика состояний для каждого отдельно)

Другим методом, который мы можем использовать для разлома нашего приложения, является разделение наших модулей по маршруту. Эта разбивка позволяет нам писать изолированные тесты, которые фокусируются на функциональности для каждого маршрута. Модуляция по маршруту может в большей степени, в зависимости от проекта; это позволяет эффективно делить нашу функциональность когда имели дело с множеством независимых маршрутов. Например:

angular.module('myApp.home', []);
angular.module('myApp.login', []);
angular.module('myApp.account', []);
angular.module('myApp', [
'myApp.home',
'myApp.login',
'myApp.account'
]);

Эта модуляция имеет смысл конкретно, когда речь идет о большом количестве маршрутов и/или когда у нас не слишком много перекрестка между маршрутами

4.Если я добавляю зависимость в подмодулях, они по умолчанию вводятся в основные модули?

в ближайшее время: да.:)