У программистов «от сохи» отношение к CASE, как правило, негативное на уровне «я не верю, что какие-то картинки генерируют код лучше написанного руками». В таком отношении есть своя сермяжная правда, действительно, экскаватор, в отличие от мужика с лопатой, может вырыть не всякую яму. Доказывать обратное – бесполезная потеря времени.
У более продвинутых программистов, имевших опыт написания и сопровождения тысяч строк однотипного рутинного кода, претензии становятся обоснованными и касаются, как правило, следующих сторон применения CASE-средств:
• Если ручное написание кода принять за максимальную гибкость, то CASE может навязывать каркас, стиль кодирования и шаблоны генерации частей программ, ограничивающие не столько полёт фантазии программиста, сколько возможность тонкой настройки генерируемого кода. Неважно, что такая настройка не требуется в большинстве случаев, но если её нет, то менять придётся непосредственно сгенерированный код.
• CASE работает только в условиях дисциплины, когда ручные изменения генерируемого кода исключены или автоматизированы (пост-обработка). Как только программист залезает руками в код каркаса, модель оказывается рассинхронизированной по отношению к исходным текстам программ и процесс разваливается.
В качестве решения перечисленных проблем появились так называемые двусторонние CASE-инструменты (two way tools), позволяющие редактировать как модель, непосредственно видя изменения в коде, так и, наоборот, менять код с полу– или полностью автоматической синхронизацией модели. Зачастую, такой инструмент был интегрирован прямо в среду разработки.
Рис. 17. Двусторонний CASE-инструментарий ModelMaker имеет возможности работы как с моделями, так и непосредственно с кодом приложения
Рис. 18. Работа с кодом приложения в ModelMaker
Нетрудно заметить, что двунаправленный подход в CASE-инструментарии в большей степени является мощным средством автоматизации отдельных программистов, так как обладает рядом ограничений:
• как правило, инструмент привязан к языкам и платформам;
• технология не выходит за рамки разработки конкретных программ и подсистем. То есть слои системы и архитектура остаются за рамками процесса;
• коллективная работа над моделями одновременно с кодом практически невозможна: приходится делить модели на независимые части, например подсистемы, разрабатываемые одним программистом;
• для достижения нужного эффекта методика по-прежнему требует навыков моделирования как минимум на уровне диаграммы классов. В противном случае CASE оказывается лишь очередным инструментов рефакторинга.
Следующим шагом в развитии автоматизированных средств софтостроения явилась программная фабрика – синтез подходов управляемой моделями разработки и архитектуры, генерирующий не только отдельные компоненты системы, но целые слои в соответствии с выбранной архитектурой и платформами.
На рынке уже имеется немало продуктов типа «software factory», если вы наберёте в поисковике эти ключевые слова, то получите множество ссылок на концепции и частные реализации. Например, неплохое руководство, хотя и привязанное к собственным средствам, составили в IBM[24]. Чтобы не утомлять вас текстами академического характера, в следующей главе я просто приведу пример одной фабрики под названием Genie Lamp (http://genielamp. sourceforge.net), применяемой непосредственно в различных моих проектах. Несмотря на то что подход УМР я использую с конца 1990-х годов, свести многие частные решения в несколько более общее удалось только за последние 2–3 года. Лень – двигатель прогресса, особенно когда надоедает переписывать генераторы кода и подстраивать относительно стандартные модели под частные требования.
Лампа, полная джиннов
Метафора системы достаточно проста: хочешь генерировать код компонента или слоя – попроси об этом соответствующего «джинна» в форме стандартного «заклинания». Джинны, как им и положено, живут в лампе.
Переходя к техническим терминам, программист описывает задачу в терминах логической модели, представляющей собой набор сущностей, их атрибутов, операций и связей между ними. Язык создан на основе XML, поэтому делать описания можно непосредственно руками в обычном текстовом редакторе.
Рис. 19. Общая схема работы с «лампой» и «джиннами»
Модель в виде XML-файлов поступает на вход «заклинателю» – входящей в состав пакета консольной утилите. Производятся проверки непротиворечивости модели, выдающие ошибки либо предупреждения разной степени важности. Во время анализа модель также преобразуется во внутренний формат в виде множества объектов с открытыми интерфейсами доступа.
Если модель корректна, «заклинатель» начинает призывать «джиннов» сделать свою работу, передавая каждому на вход кроме самой модели ещё и разнообразные параметры, конфигурацию, касающуюся не только самих джиннов, но и, например, таких настроек, как правила именования в конкретном слое системы.
Обработав модель в соответствии с конфигурацией проекта, джинн выдаёт готовый к компиляции в среде разработки код. Для слоя хранения данных кроме генерации специфичных для СУБД SQL-скриптов производится их прогон на заданном сервере разработки.
В случаях, когда система уже существует и подлежит, например, переделке, можно восстановить модель из схемы базы данных. Конечно, даже теоретически такое восстановление не может быть полным из-за разницы в семантике, но большую часть рутинной работы оно выполняет. Проведя один раз импорт, далее мы редактируем, структурируем модели и продолжаем работать только в обычном цикле изменений «через модель».
На что похожа логическая модель? Приведу пример описания из рабочего проекта, содержащего один пользовательский тип, один перечисляемый тип, две сущности и одну связь (отношение) между ними.
Пример модели в Genie Lamp
Создает периоды финансового года
между датами начала и окончания
в соответствии с грануляцией. Например, для фин. года,
совпадающего с календарным, и помесячной грануляцией
будут созданы 12 месячных периодов
Возвращает ID периода по заданной дате, "0" если не найден
name="periodDate" type="datetime"/>
entity2="FiscalYear" name2="Periods"
cardinality="M:1">
Теперь необходимо задать конфигурацию в описании проекта. Предположим, что мы хотим создать 3-звенное приложение со следующими логическими слоями:
• слои хранения будут развёрнуты на SQL Server или Oracle;
• слой домена под управлением NHibernate;
• слой веб-служб на базе ServiceStack (вместо WCF, имеющего под Mono/Linux ограничения).
Пример конфигурации проекта в Genie Lamp
type="GenieLamp.Genies.SqlServer.SqlServerGenie"
assembly="GenieLamp.Genies.SqlServer"
active="false"
outDir="%PROJECT_DIR%/../SQL/SqlServer-%TARGET_VERSION%"
outFileName="%PROJECT_NAME%.sql"
updateDatabase="true"
targetVersion="2008">
name="Database.Create" value="false" />
… Другие параметры "заклинания"
type="GenieLamp.Genies.Oracle.OracleGenie"
assembly="GenieLamp.Genies.Oracle"
active="true"
outDir="%PROJECT_DIR%/../SQL/Oracle-%TARGET_VERSION%"
outFileName="%PROJECT_NAME%.sql"
outFileEncoding="iso-8859-1"
updateDatabase="false"
targetVersion="10g">
name="UniqueIndexConstraint" value="true" />
…
type="GenieLamp.Genies.NHibernate.NHibernateGenie"
assembly="GenieLamp.Genies.NHibernate"
active="true"
outDir="%PROJECT_DIR%/../Domain"
outFileName="%PROJECT_NAME%.Domain.cs"
targetVersion="*">
name="TargetAssemblyName" value="Company.Business.%PROJECT_NAME%.
Domain" />
для генерации интерфейсов к веб-службам – >
type="GenieLamp.Genies.ServicesLayer.ServiceStack.ServicesInterfacesGenie"
assembly="GenieLamp.Genies.ServicesLayer"
active="true"
outDir="%PROJECT_DIR%/../Services.Interfaces"
targetVersion
="*">
для генерации собственно веб-служб – >
type="GenieLamp.Genies.ServicesLayer.ServiceStack.ServicesGenie"
assembly="GenieLamp.Genies.ServicesLayer"
active="true"
outDir="%PROJECT_DIR%/../Services"
targetVersion="*">
name="PrimaryKey.ColumnTemplate" value="NI%TABLE%" />
name="PrimaryKey.ConstraintTemplate" value="PK_%TABLE%" />
… Другие шаблоны именований
name="ForeignKey.CreateIndex" value="true" />
name="BooleanValues" value="YesNo"/>
name="BaseNamespace" value="Company.Business.%PROJECT_NAME%" />
name="BaseNamespace" value="Company.Business.%PROJECT_NAME%" />
name="Schema" value="Core" />
name="PersistentSchema" value="CORE" />
name="RegistryEntity.Name" value="EntityRegistry" />
name="TypesEntity.Name" value="EntityType" />
name="TypesEntity.PrimaryId.Type" value="smallint" />
name="PrimaryId.Type" value="bigint" />
name="Attribute.Name" value="Version" />
name="Attribute.Type" value="int" />
В описании конфигурации джиннов видно, что его основу составляет сборка, один из классов которой, реализующий интерфейс IGenie, является точкой входа. Каждый джинн имеет как общие для всех параметры, например каталог для выходных файлов, так и специфичные, передаваемые через тег Param, описываемые в документации.
За джиннами следуют конфигурации слоёв. Если для домена и служб можно пока ограничиться спецификацией базового пространства имён, то для слоя хранения, особенно при поддержке более чем одной СУБД, необходимо указать дополнительные ограничения вроде максимальной длины имён.
Заключительная часть конфигурации представляет собой описания шаблонов. Но не тех, о которых идёт речь в книжке «банды четырёх», а о шаблонах реализации типовых задач уровня ядра и системных служб:
• Например, шаблон «Реестр объектов» добавляет к системе возможность ведения централизованного реестра всех создаваемых объектов. Реализован он как соответствующий класс и таблица, ссылка на которые добавляется ко всем другим классам (некоторые классы можно исключить через параметры шаблона).
• Шаблон «Версия состояния» является встроенной в NHibernate возможностью отслеживания конфликтов в многопользовательской среде. Например, если два пользователя изменяют один и тот же объект, то последний из них, сохранивший объект, получит исключение, оповещающее о том, что данные были изменены со времени последнего редактирования. Шаблон реализуется добавлением соответствующего атрибута номера версии ко всем классам.
• Шаблон «Аудит» в простейшем варианте является регистрацией для каждого хранимого объекта информации о времени его создания, последнем редактировании и авторе.
• Шаблон «Локализация» добавляет в генерируемый код возможность перевода сообщений в рамках технологии GNU gettext.
• Наконец, шаблон «Безопасность» в простейшем варианте ограничивает доступ к веб-службам через механизм аутентификации, логику которой необходимо реализовать в переопределяемом методе соответствующего класса. Например, обратиться к стороннему LDAP или непосредственно к базе данных с регистрационной информацией для проверки имени пользователя и хеша пароля.
Теперь, если запустить «заклинатель» с параметром файла конфигурации проекта и не будет обнаружено ошибок, на выходе мы получим инициализированные структуры баз данных и готовые к компиляции файлы. Рассмотрим их чуть подробнее.
Слой хранения (СУБД)
Джинны SQL Server и Oracle создадут нам в указанном каталоге подкаталоги, соответствующие целевой СУБД и её версии. В каждом подкаталоге находятся три SQL-скрипта, предназначенные, соответственно, для создания, обновления или удаления схемы БД.
Если посмотреть на созданные в СУБД структуры, то мы увидим, что из одной и той же модели логического уровня были созданы две реализации, различающиеся на физическом уровне. Например, используемые типы данных различаются. С другой стороны, необходимость поддержки слоем домена сразу двух СУБД приводит к тому, что вместо оптимального, но специфичного для SQL Server типа bit для поддержки булевых величин используется принятый в среде Oracle символьный тип.
Рис. 20. Результат работы джинна SQL Server
Рис. 21. Результат работы джинна Oracle
Слой домена (NHibernate)
Джинн NHibernate генерирует три C#-файла и один XML-файл проекции (маппинга) классов на структуры хранения.
Все классы домена являются расширяемыми (partial), что позволяет разработчику вынести специфичные не поддерживаемые моделью реализации свойств и методов классов в отдельные файлы.
Перечисляемый тип создаётся вместе с классами, позволяющими локализовать пользовательские названия его элементов, описанные в модели. По умолчанию будет использован язык модели, перевод необходимо осуществлять в технологии gettext.
Рис. 22. Перечисляемый тип слоя домена и его локализация
Рис. 23. Класс «Финансовый год» слоя домена
Для определяемых моделью сущностей генерируются классы, содержащие кроме соответствующих объявленным атрибутам свойств ещё и группу служебных методов для управления объектами, например, для сохранения или выборки по запросу на HQL или даже SQL. Такие методы часто используют служебные классы, объявленные в DomainSupport.cs.
Для объявленных в модели операций генерируется соответствующий метод интерфейса. Реализовать их нужно программисту в рамках расширения partial-класса.
Рис. 24. Класс «Учётный период» слоя домена
Отображение классов на структуры РСУБД соответствует стратегии «одна таблица на подкласс без дублирования атрибутов предка», достаточно хорошей в большинстве случаев, но и она может быть изменена.
Фрагмент файла проекции для класса «Финансовый год»
name="sequence">MYAPP.SEQ_FISCAL_YEAR
Слой веб-служб и интерфейсов доступа (ServiceStack)
Генерируемые для слоя веб-служб C#-файлы предназначены для создания двух сборок: собственно служб и интерфейсов к ним, используемых клиентами.
Рис. 25. Классы, реализующие службы доступа к объектам домена
Рис. 26. Класс службы сохранения объектов
Интерфейсы доступа к службам также содержат описания перечислимых типов с локализацией, классы DTO для передачи состояния между программой-клиентом и доменом, классы для непосредственного доступа к вызовам служб.
Рис. 27. Перечисляемый тип слоя веб-служб
Рис. 28. Классы вызова специфицированных методов
Рис. 29. Классы вызова веб-служб, касающихся «финансового года»
Рис. 30. Класс адаптера для работы с объектом «Финансовый год»
Рис. 31. Класс адаптера для работы с коллекцией объектов «Финансовый год»
Работать с DTO и коллекциями не слишком комфортно, проявляется много ненужных деталей. Но если обернуть операции с DTO адаптерами, то код становится гораздо более читаемым и коротким.
Пример работы с DTO
CurrencyDTO curr1 = new CurrencyDTO();
curr1.Code = "RUR";
curr1.Name = "Currency 1";
UnitOfWorkDTO uow = new UnitOfWorkDTO();
uow.Save(curr1);
PersistenceRequest prq1 = new PersistenceRequest();
prq1.UnitOfWork = uow;
PersistenceResponse prr1 = client.Post
Assert.IsFalse(prr1.CommitResult.HasError, prr1.CommitResult.Message);
Пример работы с адаптерами
Currency curr1 = new Currency();
curr1.Code = "RUR";
curr1.Name = "Currency 1";
CommitResult cr1 = curr1.Save();
Assert.IsFalse(cr1.HasError, cr1.Message);
Программа-клиент
В рамках простейшего WinForms-приложения создадим форму, содержащую сетки отображения финансовых годов и их периодов. Не вдаваясь в технику разработки приложений этого типа, просто приведу фрагменты кода, запрашивающие у служб коллекции соответствующих типов.
Извлечение списка финансовых годов, отфильтрованного по названию
FiscalYearCollection years = FiscalYearCollection.GetByQuery(
"from FiscalYear where Name like: name order by Name",
new ServicesQueryParams()
AddParam("name", txtYearName.Text)
);
dgvYears.DataSource = years;
Извлечение списка учётных периодов заданного года
PeriodCollection periods = PeriodCollection.GetByQuery(
"from Period where FiscalYear.Id =:yearId order by FromDate",
new ServicesQueryParams()
AddParam("yearId", CurrentYear.Id),
0, 1000);
dgvPeriods.DataSource = periods;
Запускаем клиентское приложение, предварительно запустив сервер веб-служб, и видим на экране примерно такую картинку, как на рис. 32.
Рис. 32. Форма отображения финансовых годов и учётных периодов