EF5 типы поддерживаемых сущностей

В результате копания во внутренностях EntityFramework я наткнулся на change-tracking proxies, которые с одной стороны натолкнули меня на мысль создания self-tracking objects для обычных объектов с помощью PostSharp. Однако перед началом рассказа о прокси-объектах изменения состояния, стоит рассказать о других классах объектов поддерживаемых  EF. Далее идет их описание в хронологическом порядке, как они был реализованы/введены во фреймворк.

Сущности, наследуемые от EntityObject

Единственный тип сущностей, поддерживаемый в самой первой предварительно реализации EF, были классы наследуемые от класса EntityObject, входящего в пространство имен EF. Наследование от EntityObject предоставляло ряд сервисов, таких как:

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

Существование такого базового класса позволяло весьма эффективно EF управлять сущностями.

Минусом такого подхода, и очень БОЛЬШИМ минусом , было то, что бизнес-объекты и слой доступа данных (EF) были связаны более чем тесно, к тому же это нарушает принцип persistence-ignorance, т.е. объект не должен знать и завязываться на то как именно он сохраняется. Это была одна из причин, по которой я долгое время игнорировал и не стремился использовать в работе Entity Framework. К тому же, на практике, наследование от EntityObject делало работу с бизнес-объектами сложнее и полной специфичного для EF кода.

Сущности, наследуемые от EntityObject поддерживаются EF1 и EF4, но не DbContext и CodeFirst, которые были введены в версиях EF4.x.

Подробнее

EF5 шаблонный AddOrUpdate

Сложность 400

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

Одним из таких сценариев, который дает о себе знать сразу, как только вы начинаете использовать EntityFramework в более-менее настоящем проекте, а не в синтетических тестах и приложениях – это вопрос добавления и обновления данных.

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

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

Подробнее

EF5 Описание команд миграции

Основное управление скриптами миграциями для Entity Framework осуществляется из консоли менеджера пакетов, которая суть есть PowerShell, и во многих уроках и разборах упоминаются лишь базовые команды и опции, и не особенно фигурируют другие возможности. Решено было озаботиться составлением такого списка.

Основных команд, как и ожидалось всего 4:

  • Enable-Migrations – включает возможность миграции в EF
  • Add-Migration – добавляет/генерирует новую миграцию
  • Update-Database – обновление базы данных
  • Get-Migrations – показывает какие обновления были применены к БД

EF5 RF CF — Force Recovery Mode

Сложность 200

Или как заставить базу думать, что у вас новая модель.

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

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

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

Подробнее

TFS Aggregator

Или как автоматизировать некоторые действия в TFS 2010.

Сразу скажу, что для TFS 2012 автор обещает быстро выпустить обновленную версию, однако, на мой взгляд, с учетом того, что API не поменялось или мало поменялось, то данный небольшой проект вполне может завестись и на новом TFS 2012 RC.

Идея

Последние статьи повествуют о настройке шаблонов процессов для TFS, но данные шаблоны оторваны друг о друга, по сути, хотя и связываются в работе связями типа: Child, Parent, Related To и так далее. Было бы логично использовать эту связь, для добавления интерактивности во всю схему, чтобы элементы действительно были связанны, чтобы они действительно реагировали на состояния друг друга в зависимости от типа связи и состояния. Чтобы можно было делать некоторые аккумулирующие подсчеты в метриках, ведь все эти данные доступны и их можно использовать в автоматическом режиме, сокращая время рутинных действий.

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

Например, представим себе ситуацию, когда пользовательская история имеет полный набор артефактов и готова к работе, созданы конкретные задания для реализации этой истории. В данной ситуации история находится в состоянии Ready For Development, а все задачи в состоянии Proposed. Разработчик берет задачу в работу, меняет ее состояние на Active. Далее он должен поменять состояние истории на WIP (Work In Progress). Однако этот шаг ведь можно автоматизировать! А автоматизация в свою очередь ведет к большему порядку и красоте. Т.е. как только разработчик взял задачу в работу, состояние всей истории поменялось автоматически!

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

Так же полезным функционалом было бы, когда все задачи решены, то статус истории автоматически переходит в состояние Resolved.

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

Подробнее

Шаблон Agile в TFS2010 и TFS2012

После всех описаний существующего шаблона и модификаций для TFS2010, сподобился посмотреть, как это все выглядит в новом TFS, тем более что совсем недавно вышел Release Candidate и его можно поставить локально, чем я и занялся на досуге. Результатом был приятно удивлен.

Вместе с TFS2012 RC вышел и TFS Power Tools для него, что позволяет наглядно отобразить схему перехода состояний. Схема работы с TFS Power Tools не изменилась, так что сразу перейдем к рассмотрению различий.

Первое, что бросается в глаза, это более широкий набор рабочих элементов.

Некоторые элементы были переименованы, некоторые ушли, некоторые появились, рассмотрим, как элементы из TFS2010 соответствуют элементам из TFS2012:

Назначение TFS2010 TFS2012
Основной рабочий элемент, единица работы. Task Task
Запрос на новый функционал, бизнес-история. User Story Product Backlog Item
Баг Bug Bug
Затруднение в работе Issue Impediment
Тестовый сценарий Test Case Test Case
Общие шаги для тестовых сценариев Shared Steps Shared Steps

Подробнее

Настройка процессов в TFS – II

В прошлый раз я рассказал о том, как, на мой взгляд, должны выглядеть карты процессов для пользовательской истории, задачи, бага (UserStory, Task, Bug). В этот раз я хочу рассказать, как все это настроить в Visual Studio.  Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

После установки TFS Power Tools, в VS должен появиться новый пункт в меню Tools.

На скриншоте уже показано, что необходимо сделать для того, чтобы начать редактировать элементы задач. Tools > Process Editor > Work Item Types > Open WIT from Server. Такой выбор позволит сразу получить изменения на сервере. В целом все пункты последнего меню говорят сами за себя и с минимальными экспериментами можно получить представление об их действии.

Подробнее

Настройка процессов в TFS

Сложность 100

Речь пойдет о том, как можно расширить стандартный процесс (workflow) для некоторых элементов в TFS при выборе шаблона Agile для проекта.

Стандартные настройки проекта out-of-box на мой взгляд достаточно бедны и не обеспечивают должной прозрачности, если необходимо отслеживать/контролировать работу над проектом распределенной команды, либо когда управляющий (менеджер или еще какой-нито начальник) желает видеть как идут дела с задачами. Стандартные настройки не позволяют, на мой взгляд, уверенно говорить о текущем состоянии задач.

Обычная рабочая доска (task board) имеет больше состояний, нежели базовые настройки типичных артефактов управления проектом из которых строится процесс Agile: UserStory, Task, Bug. Мне кажется это базовые вещи, которые стоит рассмотреть и дополнительно настроить, что собственно я и сделал для себя и команды.  В рассказе ниже я затрону только настройку процесса перехода состояний, не затрагивая свойства элементов. Т.е. никаких кастомизаций внешнего вида и свойств не будет.

Прежде чем двигаться дальше, расскажу, какие инструменты вам понадобятся. Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

Подробнее

EF5 RC CF — Механизм миграции

Entity Framework 5 Release Candidate Code First: Механизм миграции

Сложность 200.

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

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

Подготовка

Нам понадобится база данных MS SQL. В моем случае это SQL Server 2012, вы можете поставить себе Express версию, хотя скорее всего она уже есть у вас. Далее понадобится .net framework не ниже 4 версии. Конечно же Visual Studio и менеджер пакетов NuGet.

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

Подробнее

GUID в роли быстрого первичного ключа для разных БД

Эта статья раскрывает подходы по использованию GUID в роли первичного ключа или кластерного индекса при этом описываются способы обхода основных неудобств связанных с GUID, на основании COMB модели для последовательных значений GUID разработанных в статье Джимми Нильсона. Большинство реализаций являются специфичными для MS SQL Server, в то время как основная идея похоже используется во многих библиотеках и фреймворках(включая NHibernate). В статье предпринимается попытка использовать общий гибкий подход для возможности использования COMB в других популярных базах данных: Oracle, PostgreSQL, MySQL. Так же мы рассмотрим некоторые особенности .net в свете наших задач.

Проблематика GUID

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

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

Одной из альтернатив становится использование GUID в роли первичного ключа. GUID — это 128-битное значение, которое поддерживает разумно-гарантированную уникальность независимо от времени и пространства. Стандарт для создания GUID описан в документе RFC 4122, но большинство современных алгоритмов по созданию GUID используют либо очень большое случайное число, либо формируют значение исходя из некоторой случайной информации комбинированной с чем-то локальным (ранее такое формирование было у MS, они создавали GUID на основе MAC адреса, но в последствии это было не безопасно и так же нарушало privacy).

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

Так в чем же проблема?

Подробнее