OpenKit.Net

Архитектура

Понятие CMF (content management framework) имеет два значения (см. Wiki):

1. Система управления содержимым, облегчающая разработку и объединение разных компонентов программного комплекса;

2. Инструментарий для создания веб-приложений.

OpenKit.Net является фреймворком в первом значении этого понятия, в отличие от ASP.NET WebForms и ASP.NET MVC – фреймворками во втором его значении.

Если фреймворки MVC и WebForms рассматривают внутренние слои отдельного приложения, то OpenKit.Net рассматривает отдельное приложение как часть программного комплекса. Роль программного комплекса может играть и web-сайт. Поскольку web-сайт является всего лишь точкой присутствия в Интернете, то в ней может быть сконцентрирована функциональность целой корпорации, не говоря уже о малом предприятии.

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

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

В основе OpenKit.Net лежит понятие автономного модуля. В трактовке данного решения, автономный модуль включает в себя как объектную модель прикладной области (вместе с уровнем данных), так и экраны для управления этими объектами. Автономные модули объединяются в кластер, который представляет собой dll файл и является композиционной единицей web-сайта (программного комплекса).

Кластер автономных модулей в сборке.

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

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

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

Между кластерами можно создавать иерархическую зависимость. В этом случае, в верхнем кластере определяется API и далее разработку кластеров можно вести уже параллельно

Кластер модулей в виде dll включаются в web-оболочку (CMF) пользователем-администратором, который далее распределяет экраны модулей по страницам одного или нескольких сайтов. Дизайн отделен от кода и навешивается пользователем-дизайнером. Обе эти роли, плюс роль разработчика, может выполнять один человек.

Что касается экранов для web-оболочки, то дизайнеру и разработчику достаточно использовать только всем понятные HTML и JavaScript (включая фреймворки вроде JQuery). Собственные элементы управления экрана, создаваемые разработчиком, документируются непосредственно в самой сборке и их описание доступно дизайнеру в редакторе разметки каждого экрана.

Универсальность платформы .Net дает возможность использовать модули OpenKit.Net не только на web-сайте, но и в настольных, консольных и распределенных приложениях. Таким образом можно достигать бесшовности программного комплекса и текучести, переносимости функционала из web в консоль, десктоп и обратно.

Под архитектурный шаблон автономного модуля могут быть разработаны разнотипные оболочки. Предлагаемая в рамках данного проекта web-оболочка (CMF) является лишь одним из возможных вариантов. Из разнотипных оболочек можно сформировать полноценную корпоративную систему небольшого предприятия:

Структурно, она может состоять всего из двух частей:

1. API кластера модулей, общий для всех разнотипных (web, winForms, Console, Remoting Services и т.п.) приложений, разрабатываемых в компании.

2. Одна графическая или программная оболочка для каждого типа приложений, которая посредством этого API организует работу с модулями.

1. Архитектурный шаблон кластера модулей

Кластер - это абстрактный класс, наследника которого оболочка (например, CMF) ищет в сборке. Именно от этого класса CMF «узнает» о том, какая функциональность заключена в модулях сборки, имеет ли сборка нужный фасад, на основании чего выясняется, может ли она быть зарегистрирована в оболочке. Задача кластера – объединить связанные по смыслу модули. Это административная единица управления функционалом программного комплекса (web-сайта).

Фасад(например, web-фасад) Через этот класс CMF узнает, какие именно web-экраны содержатся в данной сборке и через который она работает с ними.

Экран (например, web-экран) – это класс, который предоставляет графический интерфейс для работы с какой-то частью прикладной объектной модели. Например, выводит список статей. Тем, кто знаком с ASP.NET, можно думать о нем как об ascx контроле, только размещенном не в отдельном ascx файле, а в сборке.

Модуль – это функциональная единица. Определение намеренно абстрактно для того, чтобы обеспечить архитектурную гибкость этой единице. Основой его, как правило, является объектная модель или какая-то ее часть, заключенная в сборке (в кластере). Каждый модуль в кластере может содержать много экранов, но он обязательно должен иметь один экран, запускаемый графической оболочкой по умолчанию. Такой экран должен быть один для фасада каждого типа. Графическая оболочка один экран-по-умолчанию трактует как один модуль. Соответственно, для нее количество модулей в кластере – это количество в нем экранов по умолчанию.

Точно также может быть фасад и экраны для winForms. Экраном в этом случае будет класс формы, который можно передавать с сервера в графическую оболочку на клиента по Remoting и там запускать. Идею реализации этого можно найти на сайте RSDN в статье «Использование Remoting в multitier приложениях». Также может быть создан и консольный фасад прикладной объектной модели, который может быть использован не только для непосредственной работы, но и для ее автоматических тестов.

Более детальное описание кластера и модуля находится в руководстве разработчика, а примеры исходного кода - в SDK. И то и другое находится здесь .

2. Графическая оболочка.

Главная задача оболочки – дать пользователю доступ к функционалу модулей. В оболочку как в мозаику, собираются предоставляемые ими экраны. Например, web-оболочка (CMF) организует работу с HTML экранами, а winForms оболочка – с формами. Добавление/удаление кластеров из оболочки производится тремя кнопками «Добавить», «Удалить», «Обновить». Никакие изменения в модулях оболочку в принципе затрагивать не должны.

Такая архитектура решает сразу три вопроса: корпоративного интерфейса, единой аутентификации и развертывания. Соответственно, все эти вопросы снимаются с прикладных модулей (приложений), тем самым, существенно упрощая их.

Что касается развертывания, то в случае winForms на клиентские машины достаточно поставить только оболочку, а вся прикладная начинка, включая GUI модулей, будет находиться на сервере. Таким образом, даже развертывание и сопровождение приложений winForms ничем не будет отличаться от web-приложений, требуя внесения изменения только в одном месте (на сервере), что упрощает (удешевляет) администрирование системы.

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

В итоге имеем вместо кучи разрозненных приложений написанных неизвестно как и неизвестно на чем – десятки модулей, возможно даже разнотипных, но с одинаковой архитектурой, написанных на одном языке (не считая HTML и JavaScript), по одному стандарту и объединенных в одной - двух графических оболочках. Стоимость сопровождения стремится к минимальной, корпоративная информационная система в целом упрощается и, следовательно, становится более надежной и дешевой в сопровождении.

Для небольшой компании это решение может стать недорогой альтернативой ERP и тому подобным системам. Ее разработчики могут своими силами создавать только ту функциональность, которая реально востребована на данном предприятии, не переплачивая за избыточную функциональность и недостаточную гибкость покупных решений с одной стороны и избегая «лоскутной автоматизации» из кучи разношерстных программ с другой. В зависимости от требований компании можно обойтись и одной графической оболочкой: winForms или web. Вариантом web-оболочки и является OpenKit.Net, полноценная CMS/CMF.

В зависимости от требований компании можно обойтись и одной графической оболочкой: winForms или web. Вариантом web-оболочки и является OpenKit.net, полноценная CMS/CMF.