OpenKit.Net

Определение

 OpenKit.Net  – это CMS/CMF, созданный на C#, .Net Framework 2.0. OpenKit.Net представляет собой web-оболочку (cms), которая позволяет организовать экраны модулей (автономных, раздельно компилируемых, затемненных), в страницы одного или нескольких web-сайтов. Оболочка никак не связана с назначением этих модулей, ничего не знает об их функциональности и работает с ними через единый, открытый для сторонних разработчиков, API (cmf). Это обеспечивает универсальность, широту сфер применения, OpenKit.Net при общей структурной простоте системы.

Отличие от паттернов ASP. NET WebForms ( WF) и ASP. NET (MVC)

WebForm представляет собой один из спосбов построение графического интерфейса (UI - user interface), а MVC - вариант  его отделения от логики приложения ( BL –business level). Но отделение UI от логики является лишь одним из срезов приложения. Другой, поперечный ему срез, - это декомпозиция приложения на слабосвязанные модули. Этот срез может быть полностью проигнорирован в случае простых приложений, но по мере усложнения прикладной объектной модели он приобретает все большую важность, пока не становится первостепенным. Паттерны WebForm и MVC к декомпозиции приложения на модули прямого отношения не имеют, поэтому, чем больше функциональных блоков в приложении, тем более затруднена его дальнейшая разработка и сопровождение. 

Для OpenKit наоборот: приложение – это, прежде всего, набор модулей. А как внутри модуля UI отделен от BL – дело второе, По усмотрению разработчика они могут быть смешаны в лапшу, а могут быть структурированы. Главное – это изначальное обеспечение модульности. В этом принципиальное отличие паттерна OpenKit от паттернов WebForm и MVC.

Преимущество 

Чтобы объяснить, в чем именно заключается преимущество CMF OpenKit.Net, рассмотрим наиболее распространенный подход к созданию сайтов (приложений).

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

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

Мотивация 

Одним из центральных понятий объектной технологии является модульность. Но оба паттерна ASP.NET не специализируются на поддержке модульности прикладных приложений. Они предназначены только для частного аспекта – для отделения графического интерфейса от прикладной логики. Этот недостаток пытаются компенсировать изощренностью инструментов RAD (Visual Studio), но это не решение проблемы. Как следствие, разработка приложений с большим числом слабо связанных модулей оказывается затруднительной.

Паттерн OpenKit. Net

В противовес паттернам ASP. NET, ОК создавался как паттерн для создания, прежде всего, модульных приложений. Фреймворк имеет следующую структуру:

1. Оболочка (CMS) объединяет физические модули приложения (сборки), слабо связанные или полностью автономные.
2. Сборка содержит связанные по смыслу логические модули (экраны или их группы)
3. Экран представляет пользователю фрагмент прикладной логики

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

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

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

Рис.1. Группа логических модулей в сборке.

Логический модуль – это класс экрана ( screen, viewer), наследующий определенный интерфейс. В этом выражается суть разделения UI и BL: модули для пользователя и модули по API – это разные вещи (но могут совпадать), хотя в обоих случаях речь идет об одной и той же объектной модели. Поэтому для пользователя модуль представлен экраном (одним или группой), а сторонние программные компоненты могут взаимодействовать с любым открытым классом прикладной объектной модели или слоя служб.

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

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

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

Экран - основной тип, с которым имеет дело разработчик. Он отвечает за вывод фрагмента итоговой HTML страницы и обработку AJAX запросов от этого фрагмента. Все, что относится к обработке HTTP запроса в WF или в MVC (акшены, рутеры и т.д.), в OpenKit. Net сводится всего к двум обработчикам экрана: Execute() и ExcuteAjaxCommand(). Соответствие между запросом и экраном определяется оболочкой – разработчику об этом думать не нужно.

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

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

У экрана есть эквивалент элементов управления, но они проще, чем в ASP. NET: это XML подобные фрагменты с одинаковой для всех экранов структурой. В них можно класть что-угодно – валидации XML там нет. Такая разметка может содержать фрагменты HTML и настройки отображения контента. В момент сохранения шаблона она преобразуется в легкие структуры, которые затем при выполнении запроса десериализуются и передаются в методы экрана. Для каждого экрана разработчик создает свои элементы, но их может и не быть. Пользовательская документация по ним включается непосредственно в класс экрана. Для создания экрана достаточно HTML ,JavaScript (можно JQuery) и С#( VB). 

Между кодом и дизайном прямой зависимости нет. Дизайн состоит только из стандартного HTML, CSS и JavaScript. Дизайнер может не знать ничего другого, поэтому сторонняя разработка дизайна вполне реальна, Для соединения с сайтом, исходный HTML шаблон нужно только правильно разбить на фрагменты между шаблоном страницы и шаблонами модулей ( copy&paste ).

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

Каждый экран может разрабатываться как на web сервере, так и в консоли. Для имитации HTTP запроса и контекста CMS в консоли есть специальная консольная оснастка.

Программный комплекс и паттерн OpenKit. Net

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

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

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

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

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

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

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

Точно также может быть фасад и экраны для 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.