Конвейер (Pipeline) — I

Сложность 200-400

Практически всегда темы для статей происходят из жизни, из реальных проектов и проблем, которые надо решить. Иногда делаешь как проще и быстрее, а потом уже потихоньку перерабатываешь как надо. В этот раз, скорее всего, сразу получилось как надо =)

Преамбула

Задача в общем смысле стояла примерно так:

  • С некоторой периодичностью приходят файлы данных в xml;
  • Файлы надо распарсить;
  • Проверить данные, контрольные суммы, верность указания справочников;
  • Отправить пользователю на проверку суммарные данные;
  • Сохранить данные в базу.

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

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

Подробнее

Specification для EF

Сложность 200-300

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

Некоторое время назад я писал о фасаде доступа к данным на основе Linq2Sql и в этом подходе важную роль играл паттерн «спецификация», с помощью которого модифицировались запросы к базе данных для получения минимальной выборки, чтобы процесс фильтрации проходил средствами SQL сервера, что правильно. Хотелось бы данный подход распространить и на EF, однако все оказалось на первый взгляд не так просто и радужно как в L2S. Однако с помощью интернета и смекалки все трудности были успешно разрешены, и сейчас я расскажу, как это было решено.

Подготовка

Перед тем как собственно приступить к рассказу о реализации, необходимо немного времени уделить подготовке кода и исходных данных, с которыми будем работать. Использовать я собираюсь EF5 RC Code First и соответственно .Net 4.5. В качестве модели данных пусть у нас будет класс героев, для разнообразия (правда со свойствами класса фантазия наверно подкачала).

Заполнение базы будем делать с помощью специального класса HeroicInitializer, приведу пару строчек заполнения:

Подробнее

Фасад доступа к данным — Оптимизация, Заключение

Построение запросов

Уже традиционно покажу сразу UML схему, чтобы вы смогли ощутить какие классы будут рассмотрены и как они зависят друг от друга.

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

Linq2Sql позволяет гибко работать с запросами в стиле fluent interface переводя их в sql запросы. Было бы упущением не воспользоваться этой возможностью в полной мере. Особенно учитывая то, что мы уже работаем с логическими таблицами L2S, которые реализуют интерфейс IQueryable. Да, когда мы в адаптере чтения обращаемся к контексту с методом GetTable<TData>(), мы получаем объект, который можно донастраивать с помощью методов Where(), разбирая пользовательские спецификации. Собственно в этом и состоит идея.

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

Модифицировали запрос, если надо, и отдали его обратно. Отлично, теперь рассмотрим как это может быть реализовано.

Подробнее

Фасад доступа к данным — Фасад и Адаптер чтения

Фасад

Теория

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

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

Про Unit of Work (UoW) рассказано было ранее, паттерн Specification так же уже рассматривался, так что на этих типах данных останавливаться не будем.

Общий принцип работы такой:

  • Получаем фасад;
  • Вызываем метод получения доменных данных, в который передаем ограничивающие условия, которым должны соответствовать элементы;
  • Что-то делаем с данными, работаем с UoW;
  • Вызываем метод сохранения UoW.

Фасад доступа к данным — Подготовка

На основе LINQ to SQL

Сложность по шкале Microsoft 300-400

Сразу признаюсь, что я люблю Linq2Sql и не люблю Entity Framework. Люблю компактные API и не люблю развесистые классы с кучей методов служебных выставленных наружу. Может по этим причинам, а может быть по каким-то еще, но я использую схему доступа к данным, которую собираюсь описать ниже, уже несколько лет. По большей части меня она радует и выполняет свои задачи хорошо для большинства заданий возникающих на работе.

Вводная часть

Как уже ясно из названия, речь пойдет о паттерне Фасад. Вот что нам говорит википедия по поводу этого шаблона:

Шаблон Facade (Фасад) — Шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.

Однако сам по себе фасад достаточно тривиален и ограничиться только описанием применимости паттерна в случае баз данных было бы не очень интересно и информативно. Я планирую рассмотреть всю цепочку классов и данных, которые участвуют в получении данных, от записей в базы данных до доменных классов. Описать пути преобразования данных, оптимизацию запросов, сложные моменты в реализации, ограничения технологии, случаи, когда данный подход не оправдает себя.

Итогом работы будет являться использование фасада в таком духе:

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

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

Подробнее

Notepad – –

Это несколько необычная статья в сравнении со всеми предыдущими, потому что это скорее как аккумулирование и сумма предыдущих статей этого сезона. Это пример взаимодействия компонентов о которых я писал недавно: межпроцессное взаимодействие, менеджер команд, регистрация расширений. Пример назвал я так, потому что примером был выбран Notepad++, но в виду того, что эта программа только демонстрирует возможнсти в условиях приближенным к боевым, то получается минус-минус.

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

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

Подробнее

Command Manager

Сегодня я хочу рассказать про шаблон Команда и Менеджер команд. Все к этому плавно и шло. В прошлой статье это так и напрашивалось, но мне было лень это туда вкручивать, решил рассказать отдельно. Хотя сначала у меня были сомнения в том, как это рассказывать и нужно ли вообще. Потому что я с ходу накидал 5 способов реализации (по мере усложнения и развития идеи, но потом один все же забраковал) и этот функционал в еще большей степени развит и встроен в WPF. В итоге я думаю это будет полезно новичкам, чтобы было лучше понятно как это использовать в дальнейшем, в WPF, да и вообще.

Начнем с официальной части, вот что говорит нам википедия по поводу назначения этого шаблона:

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

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

Подробнее

Шаблон проектирования «Спецификация»

Disclaimer

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

О шаблонах проектирования

Википедия дает следующее определение:

Шаблоны проектирования, паттерны проектирования (англ. design pattern) — это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения. Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код.

Образно говоря, можно представить, что вы решаете задачу «по аналогии». Или, например, решение того же самого уравнения, но с другими конкретными числами.

Шаблон «Спецификация» – является шаблоном поведения приложения. Результатом выполнения будет являтся булевская переменная, подав которую на вход оператора условного перехода можно управлять поведением программы.

Ниже будут описаны приемы с помощью которых вы сможете:

  • Сделать  код более читабельным и кратким;
  • Избежать дубликации кода;
  • Облегчить внесение изменений в реализацию.

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

Подробнее