Краткое описание базы

База данных Eloquera с самого начала была написана для хранения объектов  на основе .Net Framework, что сделало возможным попытаться вобрать в себя все лучшее от объектных и реляционных баз данных одновременно, преодолев многие их различия. Теоретически Eloquera может работать с любыми языками из семейства .Net Framework, однако на практике работа проверялась пока только с C#. Главная ориентированность разработчиков на enterprise сегмент (100+ ГБ), а не на embedded решения, хотя последние тоже не обделены вниманием.

Отличительные особенности Eloquera весьма внушительны и постоянно пополняются, вот их очень краткий список:

• Сохраняет C# объекты (любые объекты любого языка на .Net платформе) без необходимости реализации специальных интерфейсов и адаптеров.
• Сохраняет Dynamic объекты с любыми полями\свойствами и может сопоставить их объектам любого типа.
• Язык запросов максимально приближен к SQL, при этом не требуется наличие какой либо реляционной SQL базы. Плюс поддержка LINQ.
• Возвращает объекты в том виде, в котором они были сохранены (включая перечислимые типы)
• Поддержка параметров в виде списков и массивов
• Регулярные выражения в запросах.
• Поддержка шаблонных объектов.
• Восстановление Read-only полей и свойств.
• Поддерживается частичный возврат объектов. Например, если вам требуется класс ForumTopic, тогда можно не подтягивать все ссылки на ForumMessages.
• Можно указать глубину объекта для возврата в запросе.
• Хранимые процедуры.

Теперь наступило время для:

• Перехватчики (OnCreation, EnrichWith)
• Дженерик типы
• Аттрибуты (DefaultConstructor, ValidationMethod, Все остальные)
• Немного о тестах

Перехватчики

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

Для постобработки существует два+ метода:

• OnCreation – принимает в качестве параметра Action, позволяет провести свою (custom) инициализацию объекта. Есть доступ к контексту SturctureMap.
• EnrichWith – принимает в качестве параметра Function. Может возвращать любой тип совместимый с запрашиваемым.
• Свои перехватчики

Продолжение первого поста о StructureMap

В первой части были освещены темы:

• Установка
• Регистрация (Основа, Профили, Плагины, Сканирование, Внедрение)

В этой части пойдет речь о:

• Конструкторы (Простые типы, Конструктор по умолчанию, Составные типы, Приведение типов, Задание аргументов)
• Свойства (Простое задание свойств, Встроенное задание свойств, Задание свойств фреймворком, Допостроение существующих классов)
• Время жизни

Конструкторы

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

Перед тем как начать описывать возможности фреймворка, надо поговорить о тестовых классах. В этот раз они будут сложнее. Наследование, конструкторы с простыми типами, с составными.

Сегодня я хочу рассказать о IoC контейнере StructureMap (и это не перевод устаревшей официальной документации), который мне приглянулся гораздо больше чем Unity. Хотя, честно сказать, мои взаимоотношения с Unity не сложились с самого начала, когда я увидел километровые файлы конфигурации к нему или же двухсот знаковые строки конфигурации в коде. Не будем о грустном.

StructureMap не только мне показался более удобным чем другие реализации DI\IoC, достаточно набрать в гугле StructureMap vs Unity и получить кучу ссылок, где люди обсуждают и показывают наглядно, что в работе самым удобным, гибким и естественным является StructureMap.

Ссылка раз, два и три. Ко всему прочему StructureMap еще и достаточно быстрый.
Вот еще очень интересные подборки материалов по сравнению фреймворков http://www.sturmnet.org/blog/2010/03/04/poll-results-ioc-containers-for-net

Я думаю можно опустить рассуждения о том, стоит ли такие контейнеры использовать в своем проекте или нет, и стоит ли писать свою реализацию. Я могу сказать, что в моей практике сначала случилось так, что были самописные реализации, которые заметно уступали по возможностям и удобству, но они решали свои конкретные задачи и этого на тот момент хватало.  С развитием проекта, как-то было недосуг переводить все на какую-то другую технологию. Потом был Unity, Unity, но в конце концов я пришел к тому, что надо попробовать StructureMap и не пожалел об этом ни разу.

В чем, на мой взгляд, плюсы StructureMap:

• Настройка с помощью DSL
• Очень гибкая настройка всего
• Простота конечного использования
• Возможности для проверки внутренних связей
• Поддержка тестирования out-of-the-box

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

Одно из самых востребованных применений аспектно-ориентированного программирования это вынос обслуживающего инфраструктурного кода, который часто повторяется в системе, в отдельный класс. Что в свою очередь является проявленем принципа единой ответственности (SRP — Single Responsibility Principle). Очень часто задачи авторизации и аутентификации разбросаны по всему коду проверяя права доступа пользователя. Следствием этого является большая трудоемкость изменений в этой немаловажной части логики, а так же ее общая проверка. Принцип единой ответственности говорит о том, что должна быть только одна причина для изменения класса, так что все что относится к авторизации и аутентификации просто просится в отдельные классы.

Основные методы аутентификации обычно не то, что используется по всему приложению. Например в веб приложениях ввод данных для аутентификации и сама аутентификация происходит на одной странице, после чего информация о пользователе хранится в каком-либо токене со сроком годности. Благодаря этому пользователь может автоматически входить в систему в течении срока работы токена. Таким образом единственным кодом, который пронизывает все страницы приложения будет проверка того, что пользователь до сих пор в системе. Конечно, вы можете использовать PostSharp для такой проверки, но это не лучший способ применения, по моему мнению.

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

По науке, тесты являются документированием системы. Грамотно написанные тесты дают понять, как работает система, как ведет себя, причем читаться все это должно как готовая спецификация на поведение системы. Т.е. в идеале должен получаться связный и понятный текст. Это идеал, к которому постепенно приближаются методы тестирования, начиная от юнит тестирования и наиболее явно проявляясь в поведенческом/приемочном тестировании, когда сами тесты уже пишутся на языке бизнеса (в этом моменте вспоминаем Fitnesse).

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

В общем, все должно быть направлено на максимальную ясность и четкость тестов, чтобы явно было видно все взаимосвязи. Чтобы можно было восстановить логику программы по одним лишь тестам. В дело читабельности пойдет не только Assert DSL (Domain Specific Language), но и именование файлов, подход Arrange Act Assert. Все это не новые подходы как оказывается, но широкой известности пока не получившие, судя по тому, что я вижу в окружающих меня проектах. Да и сам я натолкнулся на новые темы случайно, изучая исходные коды StructureMap.

Чтобы не томить, сразу расскажу какие основные шаги предлагаются для улучшения тестов:

• Именовать тестовые файлы по основному методу, который тестируется.
• Использовать DSL  для создания объектов, чтобы методы делать максимально лаконичными.
• Стараться писать тесты в стиле «один тестовый метод – один assert».
• Структурировать внутренности теста.
• Создать и использовать Assert DSL.

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

Одна из наиболее интересных и захватывающих разработок от Майкрософт в технологическом плане была представлена 8 ноября 2010 года. В этот день состоялся релиз CTP 1 SQL Server 2011 (Codename Denali). CTP доступна как в х86, так и в х64. Как и ожидалось, новый сервер принес много вкусненького для всех поклонников MS SQL будь то разработчик, администратор или бизнес аналитик.

За последние несколько лет Майкрософт внедрила много интересных технологий, которые были приняты разработчиками на вооружение. Самые значительные изменения были сделаны в 2005 SQL сервере и получили дополнительное развитие в 2008 выпуске. В этой статье (заключительной) будут рассмотрены изменения и новые возможности которые произошли в новой версии SQL Server.

Если у вас возникнут проблемы при установке сервера, то рекомендую обратиться к этой статье.
Далее пойдет речь о новшествах в SQL Server Management Studio (SSMS).

В оригинальном звучании и в жизни эта возможность звучит как With Result Set. Эта штука позволяет менять имена и типы данных в возвращаемом хранимой процедурой наборе данных.

Перед тем, как мы углубимся в детали использования данной возможности, рассмотрим, как предыдущие версии SQL серверов обходились с данными, которые возвращает хранимая процедура. Какие возможности они предоставляли для работы с результатом.

Для демонстрации работы будем использовать в качестве примера таблицу tbl_Test состоящую из 3 колонок.

Новое полезное дополнение для SQL Server 2011 (Denali) ­– выражение Throw. Разработчики на .Net уже догадались наверно, где и как оно будет использоваться.

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

Далее рассмотрим различные способы поимки исключении, которые предоставляет SQL Server начиная с версии 2000 и до версии 2011, с указанием плюсов и минусов.

В новом SQL Server 2011 (Denali) расширяются возможности команды Order By с помощью двух долгожданных дополнительных команд:

• Offset (смещение)
• Fetch First или Fetch Next (взять первые… или взять следующие…)

Offset

Использование данной команды позволяет пропустить указанное количество строк перед тем как выводить результаты запроса. Что под этим подразумевается: Допустим, у нас есть 100 записей в таблице и нужно пропустить первые 10 строк и вывести строки с 11 по 100. Теперь это легко решается следующим запросом:

Select *
From  <SomeTable>
Order by  <SomeColumn>
Offset 10 Rows

Для тех товарищей, которые практикуют .Net должен быть знаком метод расширения для коллекций Skip, который пропускает указанное количество строк. Так вот выражение Offset работает точно так же. После того как данные упорядочены каким-либо образом, можно применять выражение Offset.

Возможность, которой не удивишь нынче пользователей Oracle, DB2, PostgreSQL и множества других реляционных баз данных, наконец-то появилась и в MS SQL Server. На арене Sequence!

Sequence – генерирует последовательность чисел так же как и identity. Однако основным плюсом sequence является то, что последовательность не зависит от какой-либо конкретной таблицы и является объектом базы данных.

Рассмотрим пример скрипта написанного на SQL Server 2008. Создание простой таблицы с двумя колонками, одна из которых будет автоинкрементной.

Create Table WithOutSequence1
(
	 EmpId int identity not null primary key
	,EmpName varchar(50) not null
)

Insert into WithOutSequence1
	Select 'Violet' Union All
	Select 'Tape'

Select * from WithOutSequence1

Похожим образом создадим еще одну таблицу.

Create Table WithOutSequence2
(
	 EmpId int identity not null primary key
	,EmpName varchar(50) not null
)

Insert into WithOutSequence2
	Select 'Violet' Union All
	Select 'Tape'

Select * from WithOutSequence2

Как можно заметить из примеров, мы записали значения в таблицу при этом значение инкрементального поля автоматически и независимо от нас заполнилось. Мы не можем повторно использовать значение этого поля в другой таблице. Давайте посмотрим как можно выйти из этой ситуации с помощью Sequence.

Общий синтаксис для команды выглядит так:

CREATE SEQUENCE [schema_name . ] sequence_name
[ AS { built_in_integer_type | user-defined_integer_type } ]
| START WITH <constant>
| INCREMENT BY <constant>
| { MINVALUE <constant> | NO MINVALUE }
| { MAXVALUE <constant> | NO MAXVALUE }
| { CYCLE | NO CYCLE }
| { CACHE [<constant> ] | NO CACHE }

В течение последних лет Microsoft внедрила множество интересных технологий, которые прочно вошли в арсенал разработчиков. Кардинальные изменения были включены в SQL Server 2005, после чего SQL Server 2008 развил и укрепил успех. Denali несет в себе множество новых инструментов, а так же расширений функционала для существующих. В этой статье в деталях рассмотрим один из новых инструментов, который, я уверен, придется по душе разработчикам баз данных. Этот инструмент, фича ­ – автономные базы данных (Contained Database). Рассмотрим что они собой представляют, как с ними работать, к чему можно применить и другие вещи.

Что не так с текущими базами?

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

Вот некоторые из ключевых проблем:

• Потеря информации во время разворачивания базы или передвижения ее между серверами.
  Во время передвижения базы данных между серверами, то такая информация как логины, пароли, задания агента SQL Server и прочее не может быть передвинуто вместе с базой. Потому что эта информация принадлежит серверу баз данных.  Пересоздание упомянутых объектов  руками не самое приятное занятие, которое к тому же занимает много времени и не гарантирует защиты от ошибок.
• Различия между Разработкой и Разворачиванием приложений.
  При разворачивании приложения разработчиков могут поджидать самые разные неприятности, начиная от несовпадения тонких настроек окружения, таких как разрешения на создание новых логинов, отключенная командная строка (xp_cmdshell), языковые настройки сервера.
• Вопросы безопасности в администрировании приложения.
  Весьма сложно администрировать и поддерживать отдельно стоящую базу данных из-за того, что, например, задания агента SQL Server доступны в пределах всего сервера, что влечет за собой повышение привилегий отдельно взятых пользователей. Однако эти повышенные права дают доступ к другим частям сервера, которые не желательно открывать. Все это может вести к серьезным проблемам безопасности.

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