1. RAD и Monolithic RAD Модель Rapid Application Development (RAD) использует инструменты, позволяющие разработчикам использовать возможности таких IDE-сред, как Visual Studio. Примером использования быстрой разработки можно считать простое перетаскивание элементов управления на поверхность разработки IDE, а затем настройка этих элементов управления с помощью дизайнера IDE. Затем создается "монолитная" бизнес-логика для работы приложения. RAD - один из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ. Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента: небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Жизненный цикл ПО по методологии RAD состоит из четырех фаз: фаза анализа и планирования требований; фаза проектирования; фаза построения; фаза внедрения. -На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, описывают информационные потребности. Определение требований выполняется силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. - На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистовразработчиков. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Анализируется и корректируется функциональная модель. Далее принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. - На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям. - На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой. Методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Методология RAD неприменима для построения сложных расчетных программ, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. А также не подходят для разработки приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы. 3 основных преимущества RAD — высокая скорость разработки, низкая стоимость и высокое качество. Но самым главным преимуществом RAD-разработки, конечно, является легкость разработки. Весь код графического интерфейса и его привязки к данным генерируется IDE-средой и нам не нужно беспокоиться о деталях его реализации. Monolithic design Корпоративные приложения используются для отображения, обработки и сохранения данных. Если мы строим приложение без использования паттернов проектирования, то можем столкнуться с потенциальной проблемой при расширении графического интерфейса приложения или дополнении кода доступа к данным. На следующей диаграмме показана тенденция "монолитного" проектирования графических интерфейсов: Как видите бизнес-логика и код доступа к данным инкапсулируются глубоко в графическом интерфейсе Этот код выполняет свою работу, так в чем проблема и почему есть необходимость реструктурировать его? Этот код тесно связан с графическим интерфейсом пользователя и требует добавления множества обработчиков событий, которые конструируют логику приложения. При этом он имеет плохую расширяемость, например, если вы захотите перенести бизнес-логику данного приложения в веб-приложение, придется очень сильно реконструировать проект, т.к. бизнес-логика сильно связана с графическим представлением. 2.MVC модель-представление-контроллер (model-view-controller) - схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо. Если оперировать понятиями высокого уровня, архитектурный шаблон MVC означает, что приложение MVC будет разделено, по крайней мере, на три части: Модели - предоставляет данные и реагирует на команды контроллера, изменяя своё состояние Содержат или представляют данные, с которыми работают пользователи. Они могут быть простыми моделями представлений, которые только представляют данные, передаваемые между представлениями и контроллерами; или же они могут быть моделями предметной области, которые содержат бизнес-данные, а также операции, преобразования и правила для манипулирования этими данными. Представления (View) - отвечает за отображение данных модели пользователю, реагируя на изменения модели. Применяются для визуализации некоторой части модели в виде пользовательского интерфейса. Контроллеры изменений. интерпретирует действия пользователя, оповещая модель о необходимости Обрабатывают поступающие запросы, выполняют операции с моделью и выбирают представления для визуализации пользователю. Если рассматривать приложение в призме бизнес-логики, то можно выделить три уровня на которых строится приложение: Уровень представления - данный уровень отвечает за отображение данных, обеспечение обратной связи с пользователем, сбор пользовательской информации, которая передается в уровень бизнес-логики для обработки. Бизнес-уровень - бизнес-уровень или, если говорить проще, уровень приложения, обеспечивает логику взаимодействия представления и данных. В MVC бизнес-уровень реализует структуру модели. Уровень данных - уровень данных отвечает за получение, передачу и сохранение данных в файле, базе данных, службе или XML. Основная цель применения этой концепции состоит в отделении бизнес-логики (модели) от её визуализации (представления, вида). За счёт такого разделения повышается возможность повторного использования кода. Наиболее полезно применение данной концепции в тех случаях, когда пользователь должен видеть те же самые данные одновременно в различных контекстах и/или с различных точек зрения. Поскольку MVC не имеет строгой реализации, то реализован он может быть поразному. Нет общепринятого определения, где должна располагаться бизнес-логика. Она может находиться как в контроллере, так и в модели. В последнем случае, модель будет содержать все бизнес-объекты со всеми данными и функциями 3. MVP Model View Presenter (MVP) - шаблон, который впервые появился в IBM, а затем использовался в Taligent в 1990-х. MVP является производным от MVC, при этом имеет несколько иной подход. В MVP представление не тесно связано с моделью, как это было в MVC. На следующей диаграмме показана структура MVP: Как видно на этой диаграмме, Presenter занял место контроллера и отвечает за перемещение данных, введенных пользователем, а также за обновление представления при изменениях, которые происходят в модели. Presenter общается с представлением через интерфейс, который позволяет увеличить тестируемость, так как модель может быть заменена на специальный макет для модульных тестов. Также как и для MVC, давайте рассмотрим структуру MVP со стороны бизнеслогики приложения: В данном случае структура MVP аналогична MVC в том плане, что код доступа к данным находится вне этой модели, а вся бизнес-логика приложения концентрируется в модели (эта схожесть подтверждает то, что MVP является производным от MVC, изменилась только логика представления). MVP был разработан для облегчения автоматического модульного тестирования и улучшения разделения ответственности в презентационной логике (отделения логики от отображения): Модель (англ. Model) — хранит в себе всю бизнес-логику, при необходимости получает данные из хранилища. Вид (англ. View) — реализует отображение данных (из Модели), обращается к Presenter за обновлениями. Представитель (англ. Presenter) — реализует взаимодействие между моделью и представлением. Обычно экземпляр Вида (Представления) создаёт экземпляр Представителя, передавая ему ссылку на себя. При этом Представитель работает с Видом в абстрактном виде, через его интерфейс. Когда вызывается событие Представления, оно вызывает конкретный метод Представителя, не имеющего ни параметров, ни возвращаемого значения. Представитель получает необходимые для работы метода данные о состоянии пользовательского интерфейса через интерфейс Вида и через него же передаёт в Вид данные из Модели и другие результаты своей работы. Итак, MVP представляет собой большой шаг вперед по сравнению с MVC в нескольких направлениях: MVP обеспечивает проверяемость состояния и логики представления, перемещая их в Presenter. Представление жестко отделяется от модели, при этом связь организуется через Presenter. В отличие от MVC, MVP допускает повторное использование бизнес-логики без непосредственного видоизменения модели (за счет использования интерфейса IView). Например, если вы захотите перенести это WPF-приложение на Silverlight, вам потребуется только создать представление в Silverlight, реализующее IProjectsView, а IProjectsPresenter и IProjectsModel можно использовать повторно. 4. MVVM MVVM (Model-View-ViewModel) - это шаблон, который появился для обхода ограничений паттернов MVC и MVP, и объединяющий некоторые из их сильных сторон. Эта модель впервые появилась в составе фреймворка Small Talk в 80-х, и была позднее улучшена с учетом обновленной модели презентаций (MVP). Шаблон MVVM имеет три основных компонента: -модель, которая представляет бизнес-логику приложения; -представление пользовательского интерфейса XAML - графический интерфейс, то есть окно, кнопки и т. п. Представление является подписчиком на событие изменения значений свойств или команд, предоставляемых Моделью Представления. -представление-модель, в котором содержится вся логика построения графического интерфейса и ссылка на модель, поэтому он выступает в качестве модели для представления. На следующем рисунке представлена диаграмма, которая показывает, как реализовать шаблон MVVM. Конечно, это общая реализация: MVVM используется для разделения модели и её представления, что необходимо для изменения их отдельно друг от друга. Например, разработчик задает логику работы с данными, а дизайнер соответственно работает с пользовательским интерфейсом. MVVM удобно использовать вместо классического MVC и ему подобных в тех случаях, когда в платформе, на которой ведётся разработка, присутствует «связывание данных». В шаблонах проектирования MVC/MVP изменения в пользовательском интерфейсе не влияют непосредственно на Mодель, а предварительно идут через Контроллер (англ. Controller) или Presenter. В таких технологиях как WPF и Silverlight есть концепция «связывания данных», позволяющая связывать данные с визуальными элементами в обе стороны. Следовательно, при использовании этого приема применение модели MVC становится крайне неудобным изза того, что привязка данных к представлению напрямую не укладывается в концепцию MVC/MVP. 5.DAL Слой доступа к данным -DAL (Data Access Layer) в программном обеспечении — это слой компьютерной программы, который предоставляет упрощенный доступ к данным, хранимым в постоянном хранилище какого-либо типа, таком как реляционная база данных. Для архитектуры конкретного приложения входит в норму подбор средства или класса средств хранения под конкретную решаемую задачу. Для масштабных ИТ-систем оптимальным нередко становится одновременное использование нескольких БД различного типа в рамках одного приложения (гетерогенное хранение, рис. 1) для разных групп данных. модель объектов описания DAL Концепция вводит несколько понятий: класс данных; средство хранения; характеристика средства хранения; класс средств хранения; группа данных; контейнер данных Класс данных - определяет идеальную абстракцию данных, не зависящую ни от конкретных технологий, ни от ограничений реализуемости: абстрактную («логико-математическую») модель самих данных (например, «набор реляционных отношений» или «набор пар ключ-значение»); модель (или несколько моделей) доступа к данным и вычисления над данными (например, «реляционная алгебра» или MapReduce); модель безопасности (например, «именованные контейнеры», «пользователи» и «права»); модель структуры данных (например, «схема с описанием таблиц» или «перечень групп атрибутов»). Бизнес-логика приложения реализована на основе определенного класса данных, и смена класса данных никак не может произойти без перепроектирования логики приложения. Средства хранения - Конкретные имеющиеся на рынке или развернутые на предприятии средства хранения (различные виды БД) предоставляют возможности одного или нескольких классов средств хранения для нескольких классов данных. Характеристика средства хранения - Представляет собой какую-либо значимую числовую, качественную характеристику или бинарный признак средства хранения: производительность чтения/записи; масштабируемость; работа в памяти (in-memory); ограничения; специализация (например, Big Data или Fast Data); поддержка ACID-транзакций и т. д. Класс средств хранения (SLA) В рамках одного класса данных группирует такой набор характеристик хранения, который, с одной стороны, часто востребован в приложениях, а с другой — обеспечивает альтернативную реализацию (средство хранения). Для различных классов данных могут определяться разные SLA. Перевод данных приложения с одного класса хранения на другой может потребовать частичного перепроектирования, поскольку понадобится компенсация ослабевающих или пропадающих свойств SLA. Переделки также вероятны в случае необходимости выделения внутри приложения отдельной группы данных для размещения в другом классе данных или средстве хранения с последующей интеграцией этих данных с другими группами. Группа данных - Данные в рамках конкретного приложения, по логике этого приложения принадлежащие к одному классу данных и требующие одного SLA; например, в приложении может быть выделена группа данных «справочники X», принадлежащая классу key-value и требующая быстрого чтения по ключу. Контейнер данных - Идентифицируемый объем данных, хранимых с помощью некоторого средства хранения и соответствующих одной группе данных одного приложения. В ответ на запрос хранения данных для приложения выделяется один или несколько контейнеров данных. DAL образует контролируемый «слой» между бизнес-приложениями и средствами хранения (базами данных): Структура DAL представляет собой набор слабо связанных программных модулей для организации доступа к данным разных приложений. Слабая связанность модулей позволяет избежать проблем в синхронизации процессов разработки и обновления разных приложений и программного обеспечения DAL. Сами модули доступа могут иметь специфические реализации для различных базовых технологий, на которых разработаны бизнес-приложения. Структура DAL предполагает два варианта размещения модулей доступа к данным: 1. В виде библиотеки, включаемой в состав приложения. В этом варианте необходима разработка разных видов модулей доступа для разных технологий разработки АС. 2. В виде сетевого сервиса. Этот вариант предназначен для тех случаев, когда по каким-то причинам невозможна или нежелательна работа сервиса доступа к данным в виде библиотеки (например, ИС разработана на платформе, у которой нет библиотеки для работы с DAL). В таком варианте DAL доступен для любого приложения, способного работать с сетевыми сервисами по протоколу HTTP. Для этого способа размещения набор предоставляемых интерфейсов доступа к данным может быть ограничен. Если предприятие хочет сохранить независимость от поставщиков конкретных решений для ИТ-инфраструктуры, то разработчикам ИТ-систем предприятия следует максимально абстрагироваться от специфики этих решений. Следование архитектурным принципам Data Access Layer позволит предприятию не быть заложниками проприетарных СУБД и выбирать наиболее подходящее по возможностям и стоимости решение для хранения данных. Помимо этого, у компании появится возможность использования новых технологий для работы с данными без значительных доработок АС.
