Означает ли это, что если у меня есть, например, 50 компонентов, мне понадобится в 50 раз больше требований к памяти для внедренного сервиса, чем одноэлементного сервиса, который является общим для всех?
blockquote>Это произойдет, только если каждый компонент имеет свой модуль и: [ 119]
каждый модуль предоставляет услугу;
или услуга предоставляется в одном модуле, и этот модуль импортируется в каждый компонентный модуль;
Если какой-либо компонент совместно использует модуль, который предоставляет услугу, он будет единичным вокруг этих компонентов.
Я читал очень хорошую статью из Нетанела Базала - «Угловые услуги НЕ должны быть Singleton »
Где он говорит об одноэлементных сервисах:
The sole purpose of the service is to share data between child’s components and to provide a couple of helper’s methods.
Если у вас есть одноэлементный сервис, это будет только один экземпляр, но во всем жизненном цикле приложения (даже если вы его не используете), в противном случае, если у вас есть не одноэлементные экземпляры служб, они будут потреблять гораздо больше памяти, и каждый экземпляр службы будет уничтожен только после уничтожения всех компонентов его модуля.
Я бы сказал, что вы можете попытаться контролировать компромисс этих преимуществ в своем приложении.
Другое не одноразовое преимущество:
Мы даже можем реализовать жизненный цикл
ngOnInit
иngOnDestroy
, вы можете проверить его здесь .
Зависит от того, куда Ваша информация прибывает из. У нас есть стандартные данные представления, которые мы используем для генерации части информации, которую мы имеем на экране, который мы создаем просто этим способом. Это работает хорошо и легко сохраняется. Мы переопределяем Метод просмотра реализовать имена представления со строгим контролем типов и использовать эту информацию для получения некоторых данных, которых основная страница требует также.
Я отвечу на Ваш вопрос с другим вопросом. Основной контроллер должен будет определить то, что вводит его, действительно в порядке для генерации надлежащих данных меню? Если так, затем Вы побеждаете цель полиморфизма, и код для генерации данных должен войти в каждый контроллер, возможно, в OnActionExecuting, если меню является тем же для всех действий. Пододвижение обратно его вниз в родительский класс кажется вероятным закончиться с некоторым оператором переключения в выполнении родительского класса, о чем действительно должен заботиться каждый полученный контроллер.
Вы можете написать вспомогательное расширение для отображения заголовка / меню Таким образом, вы можете отображать его в разных местах в обзоре, если вам это нужно, но только в одном месте для обслуживания.
public static HtmlString MainMenu(this HtmlHelper helper)
Используйте базовый класс контроллера для реализации общих методов фильтрации. Класс контроллера реализует некоторые интерфейсы фильтров IActionFilter, IAuthorizationFilter, IExceptionFilter и IResultFilter, которые полезны для реализации некоторого общего поведения для всех контроллеров.
Если данные меню одинаковые на всех страницах, но разные для каждого уникального пользователя.
Создайте меню с помощью метода OnAuthorization
или Initialize
базового класса контроллера. Сначала будет вызвана авторизация. Initialize
будет вызываться перед каждым методом действия. У вас есть доступ к ViewData Context. Создайте там меню.
Поместите содержимое представления для меню и заголовка на главную страницу и получите доступ к сгенерированным ViewData там.
Пару месяцев назад я решал похожую задачу - реализовал функцию хлебных крошек, которые меняются при переходе пользователя со страницы на страницу.
Я переопределил метод OnActionExecuting
, чтобы собрать хлебные крошки и сохранить их в ViewData
(я использую имя действия в качестве хлебной крошки представления). Затем я обновил главную страницу, включив в нее пользовательский элемент управления, который принимает ViewData
и отображает хлебные крошки.
Следует помнить, что если вы использовали стандартный атрибут обработки ошибок ASP.NET MVC [HandleError]
и ваша страница ошибки использует ту же самую мастер-страницу, которая пытается прочитать ViewData
, вы скоро обнаружите, что не можете получить доступ к ViewData
со своей страницы ошибки, и это вызовет исключение. В зависимости от того, нужны ли вам ViewData
для сценариев ошибок, приемлемым решением будет использование отдельной страницы Master или следующее: Как передать ViewData в представление HandleError?