Третья заключительная часть перевода статьи на StackOverflow, посвященной архитектуре Composite C1: How does the architecture work? (Ссылки на англоязычные ресурсы в статье сохранены с небольшой коррекцией.)
composite.config
Фундаментальной частью C1 являются поставщики (providers), почти все состоит из поставщиков, даже большая часть функциональности ядра системы. Все в админке, начиная с разделов (perspectives) и деревьев и заканчивая элементами и действиями, поставляется в C1 поставщиками. Все стандартные функции, уровень данных и все виджеты, используемые в редакторе вызовов функций поставляются в C1 поставщиками. Все строки локализации, используемые ресурсами, пользователи и разрешения, форматировщики URL-адресов и т.п. - все это поставщики.
Далее у нас идут несколько разделов чисто для конфигурации, например, кэширования или того, что подлежит параллелизации, но это не так интересно, как тема поставщиков.
Определение и использование разделов
Разделы в composite.config и других связанных config-файлах - целиком и полностью являются стандартной .NET-конфигурацией и подчиняются ее правилам. Это означает, что для того, чтобы воспользоваться произвольным элементом, как, например, Composite.Functions.Plugins.WidgetFunctionProviderConfiguration, его нужно определить как раздел. У раздела есть название и он ссылается на тип, который наследуется от System.Configuration.ConfigurationSection. Composite C1 использует библиотеки Microsoft Enterprise Libraries для работы с большей частью этих объектов, таких как конфигурация, журналирование и проверка данных; соотвественно, все разделы Composite C1 наследуются от Microsoft.Practices.EnterpriseLibrary.Common.Configuration.SerializableConfigurationSection. Итак, такому типу нужно иметь свойства для всех элементов, которые нам нужно определять в config-файле, а .NET автоматически обеспечит нужные для нас связи.
Если вам нужен доступ к конфигурации конкретного раздела, вам следует вызвать Composite.Core.Configuration.ConfigurationServices.ConfigurationSource.GetSection(".. имя раздела") и привести его к вашему конкретному типу, и тогда у вас все готово.
Добавление дополнительных свойств к уже определенным разделам
Обычно .NET будет "жаловаться", если вы запишите элементы или атрибуты в config-файле, которые не узнаются типом, ответственным за это раздел или элемент. Из-за этого трудно написать действительно гибкую модульную систему, в которой сторонние авторы смогут добавлять конкретные конфигурационные опции к своим поставщикам, таким образом мы приходим к понятию ассемблера (Assembler). Это класс ConfigurationElement с атрибутом Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.AssemblerAttribute, который в свою очередь принимает интерфейс Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.IAssembler в качестве аргумента, ответственного за получение таких произвольных атрибутов и значений из элемента в config-файле, и генерирует на его основе используемый объект. Благодаря этому .NET не будет "жаловаться" на недопустимый config-файл, так как мы вставляем объект ConfigurationElement, у которого есть свойства для всех наших произвольных атрибутов, и мы можем получить к ним доступ при чтении конфигурации через IAssembler.
Слайды
Обзоры в виде слайдов можно посмотреть по этим ссылкам (все на англ.):
В качестве примеров
Проект C1Contrib на CodePlex является хорошим введением в тему о взаимодействии с различными частями C1. Это коллекция небольших пакетов расширения, которые можно использовать "как есть", или брать в качестве примеров для своих проектов. Некоторые пакеты манипулируют динамическими типами, чтобы сделать возможным наследование интерфейсов. В других пакетах используются программные JavaScript-интерфейсы в админке, а еще в одних демонстрируется создание поставщиков функций, деревьев, и подключение команд к существующим элементам. Есть даже примеры манипулирования через SOAP веб-службу процессом общения между клиентом и сервером, чтобы делать все именно так, как вам нужно. И список можно продолжать.
***
Ссылки по теме на некоторые материалы на русском:
composite.config
Фундаментальной частью C1 являются поставщики (providers), почти все состоит из поставщиков, даже большая часть функциональности ядра системы. Все в админке, начиная с разделов (perspectives) и деревьев и заканчивая элементами и действиями, поставляется в C1 поставщиками. Все стандартные функции, уровень данных и все виджеты, используемые в редакторе вызовов функций поставляются в C1 поставщиками. Все строки локализации, используемые ресурсами, пользователи и разрешения, форматировщики URL-адресов и т.п. - все это поставщики.
- Composite.Data.Plugins.DataProviderConfiguration
- Composite.C1Console.Elements.Plugins.ElementProviderConfiguration
- Composite.C1Console.Elements.Plugins.ElementActionProviderConfiguration
- Composite.C1Console.Security.Plugins.LoginProviderConfiguration
- Composite.Functions.Plugins.FunctionProviderConfiguration
- Composite.Functions.Plugins.WidgetFunctionProviderConfiguration
- Composite.Functions.Plugins.XslExtensionsProviderConfiguration
Далее у нас идут несколько разделов чисто для конфигурации, например, кэширования или того, что подлежит параллелизации, но это не так интересно, как тема поставщиков.
Определение и использование разделов
Разделы в composite.config и других связанных config-файлах - целиком и полностью являются стандартной .NET-конфигурацией и подчиняются ее правилам. Это означает, что для того, чтобы воспользоваться произвольным элементом, как, например, Composite.Functions.Plugins.WidgetFunctionProviderConfiguration, его нужно определить как раздел. У раздела есть название и он ссылается на тип, который наследуется от System.Configuration.ConfigurationSection. Composite C1 использует библиотеки Microsoft Enterprise Libraries для работы с большей частью этих объектов, таких как конфигурация, журналирование и проверка данных; соотвественно, все разделы Composite C1 наследуются от Microsoft.Practices.EnterpriseLibrary.Common.Configuration.SerializableConfigurationSection. Итак, такому типу нужно иметь свойства для всех элементов, которые нам нужно определять в config-файле, а .NET автоматически обеспечит нужные для нас связи.
Если вам нужен доступ к конфигурации конкретного раздела, вам следует вызвать Composite.Core.Configuration.ConfigurationServices.ConfigurationSource.GetSection(".. имя раздела") и привести его к вашему конкретному типу, и тогда у вас все готово.
Добавление дополнительных свойств к уже определенным разделам
Обычно .NET будет "жаловаться", если вы запишите элементы или атрибуты в config-файле, которые не узнаются типом, ответственным за это раздел или элемент. Из-за этого трудно написать действительно гибкую модульную систему, в которой сторонние авторы смогут добавлять конкретные конфигурационные опции к своим поставщикам, таким образом мы приходим к понятию ассемблера (Assembler). Это класс ConfigurationElement с атрибутом Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.AssemblerAttribute, который в свою очередь принимает интерфейс Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.IAssembler в качестве аргумента, ответственного за получение таких произвольных атрибутов и значений из элемента в config-файле, и генерирует на его основе используемый объект. Благодаря этому .NET не будет "жаловаться" на недопустимый config-файл, так как мы вставляем объект ConfigurationElement, у которого есть свойства для всех наших произвольных атрибутов, и мы можем получить к ним доступ при чтении конфигурации через IAssembler.
Слайды
Обзоры в виде слайдов можно посмотреть по этим ссылкам (все на англ.):
- Overview (Обзор)
- Extensibility points (Точки расширяемости)
- Page request handling (Обработка запроса страницы)
- Function system (Система функций)
- Data system (Система данных)
- Data type system (Система типов данных)
В качестве примеров
Проект C1Contrib на CodePlex является хорошим введением в тему о взаимодействии с различными частями C1. Это коллекция небольших пакетов расширения, которые можно использовать "как есть", или брать в качестве примеров для своих проектов. Некоторые пакеты манипулируют динамическими типами, чтобы сделать возможным наследование интерфейсов. В других пакетах используются программные JavaScript-интерфейсы в админке, а еще в одних демонстрируется создание поставщиков функций, деревьев, и подключение команд к существующим элементам. Есть даже примеры манипулирования через SOAP веб-службу процессом общения между клиентом и сервером, чтобы делать все именно так, как вам нужно. И список можно продолжать.
***
Ссылки по теме на некоторые материалы на русском:
Комментариев нет:
Отправить комментарий