» » » » Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

На нашем литературном портале можно бесплатно читать книгу Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри, Сергей Тарасов . Жанр: Программы. Онлайн библиотека дает возможность прочитать весь текст и даже без регистрации и СМС подтверждения на нашем литературном портале litmir.org.
Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри
Название: Дефрагментация мозга. Софтостроение изнутри
ISBN: -
Год: -
Дата добавления: 3 июль 2019
Количество просмотров: 367
Читать онлайн

Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних просмотр данного контента СТРОГО ЗАПРЕЩЕН! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту readbookfedya@gmail.com для удаления материала

Дефрагментация мозга. Софтостроение изнутри читать книгу онлайн

Дефрагментация мозга. Софтостроение изнутри - читать бесплатно онлайн , автор Сергей Тарасов
Эта книга для тех, кто давно связан с разработкой программного обеспечения. Или для тех, кто еще думает выбрать программирование своей профессией. Или для тех, кто просто привык думать и размышлять о происходящем в мире информационных технологий.Не секрет, что основная масса софтостроения сосредоточена в секторе так называемой корпоративной разработки: от комплексных информационных систем предприятия до отдельных приложений. Поэтому немалая часть сюжетов касается именно Enterprise Programming.Из текста вы вряд ли узнаете, как правильно склеивать многоэтажные постройки из готовых компонентов в гетерогенной среде, проектировать интерфейсы, синхронизировать процессы или писать эффективные запросы к базам данных. Подобные темы будут лишь фоном для рассказа о софтостроительной «кухне». При определенной доле любопытства вы сможете убедиться, что новое – это хорошо забытое старое, узнать, как устроены некоторые сложные системы, когда следует применять разные технологии, почему специалистам в информатике надо особенно тщательно фильтровать поступающую из множества источников информацию, и многое другое, что вы, возможно, еще не знали или уже знаете, но с другой стороны.В книге мне хотелось показать наш софтостроительный мир разработки корпоративных информационных систем не с парадного фасада описаний программных сред, подходов и технологий, а изнутри. Насколько это получилось – судить читателю.
1 ... 35 36 37 38 39 ... 45 ВПЕРЕД
Перейти на страницу:
Конец ознакомительного фрагментаКупить книгу

Ознакомительная версия. Доступно 7 страниц из 45

outFileName="%PROJECT_NAME%.sql"

updateDatabase="true"

targetVersion="2008">

<Param name="Database.Create" value="false" />

… Другие параметры "заклинания"

</Genie>


<! – Будем использовать джинна Oracle – >

<Genie name="OracleDb"

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">

<Param name="UniqueIndexConstraint" value="true" />

</Genie>


<! – Будем использовать джинна NHibernate для генерации домена – >

<Genie name="NHibernate"

type="GenieLamp.Genies.NHibernate.NHibernateGenie"

assembly="GenieLamp.Genies.NHibernate"

active="true"

outDir="%PROJECT_DIR%/../Domain"

outFileName="%PROJECT_NAME%.Domain.cs"

targetVersion="*">

<Param name="TargetAssemblyName" value="Company.Business.%PROJECT_NAME%.

Domain" />

</Genie>


<! – Будем использовать первого джинна ServiceStack

для генерации интерфейсов к веб-службам – >

<Genie name="ServiceStack Services Interfaces"

type="GenieLamp.Genies.ServicesLayer.ServiceStack.ServicesInterfacesGenie"

assembly="GenieLamp.Genies.ServicesLayer"

active="true"

outDir="%PROJECT_DIR%/../Services.Interfaces"

targetVersion

="*">

</Genie>


<! – Будем использовать второго джинна ServiceStack

для генерации собственно веб-служб – >

<Genie name="ServiceStack Services"

type="GenieLamp.Genies.ServicesLayer.ServiceStack.ServicesGenie"

assembly="GenieLamp.Genies.ServicesLayer"

active="true"

outDir="%PROJECT_DIR%/../Services"

targetVersion="*">

</Genie>


<Configuration>

<! – Конфигурация слоя хранения данных – >

<Layer name="Persistence">

<NamingConvention style="uppercase" maxLength="30">

<Param name="PrimaryKey.ColumnTemplate" value="NI%TABLE%" />

<Param name="PrimaryKey.ConstraintTemplate" value="PK_%TABLE%" />

… Другие шаблоны именований

</NamingConvention>

<Param name="ForeignKey.CreateIndex" value="true" />

<Param name="BooleanValues" value="YesNo"/>

</Layer>


<! – Конфигурация слоя домена – >

<Layer name="Domain">

<Param name="BaseNamespace" value="Company.Business.%PROJECT_NAME%" />

</Layer>

<! – Конфигурация слоя служб – >

<Layer name="Services">

<Param name="BaseNamespace" value="Company.Business.%PROJECT_NAME%" />

</Layer>


<! – Шаблон "Реестр объектов" – >

<Pattern name="Registry">

<Param name="Schema" value="Core" />

<Param name="PersistentSchema" value="CORE" />

<Param name="RegistryEntity.Name" value="EntityRegistry" />

<Param name="TypesEntity.Name" value="EntityType" />

<Param name="TypesEntity.PrimaryId.Type" value="smallint" />

<Param name="PrimaryId.Type" value="bigint" />

</Pattern>


<! – Шаблон "Версия состояния" для хранимых объектов – >

<Pattern name="StateVersion">

<Param name="Attribute.Name" value="Version" />

<Param name="Attribute.Type" value="int" />

</Pattern>


<! – Шаблон "Аудит" для минимального отслеживания изменений – >

<Pattern name="Audit" />


<! – Шаблон "Локализация" – >

<Pattern name="Localization" />


<! – Шаблон "Безопасность" для веб-служб – >

<Pattern name="Security" />

</Configuration>


В описании конфигурации джиннов видно, что его основу составляет сборка, один из классов которой, реализующий интерфейс 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. Класс «Учётный период» слоя домена


Отображение классов на структуры РСУБД соответствует стратегии «одна таблица на подкласс без дублирования атрибутов предка», достаточно хорошей в большинстве случаев, но и она может быть изменена.


Фрагмент файла проекции для класса «Финансовый год»


<!-Engine.FiscalYear->

<class name="Domain.Engine.FiscalYear" table="FISCAL_YEAR" schema="MYAPP">

<id name="Id" access="property" column="NIFISCAL_YEAR">

<generator class="native">

<param name="sequence">MYAPP.SEQ_FISCAL_YEAR</param>

</generator>

</id>

<version name="Version" column="VERSION" type="int" access="property" />

<set name="Periods" table="MYAPP.PERIOD" inverse="true" lazy="true" cascade="none">

<key column="NI_FISCAL_YEAR" />

<one-to-many class="Domain.Engine.Period" />

Ознакомительная версия. Доступно 7 страниц из 45

1 ... 35 36 37 38 39 ... 45 ВПЕРЕД
Перейти на страницу:
Комментариев (0)