Как реализовать управление версиями с Entity Framework

У меня есть проект, который будет построен постепенно.Как реализовать управление версиями с Entity Framework

Проект представляет собой настольное приложение, с Entity Framework с пакетами выкладывается так:

Entity Framework + DAL -> Application + Logic и т.д.

версии 1.0 были 2 объекта:

Блог
Post

Так что я Packa и отправьте его моему клиенту, он хочет несколько изменений, и я продвигаюсь вперед в целом по системе.

Версия 2.0 теперь имеет 3 объекта:

Блог
сообщение
Пользователь

С Entity Framework схема базы данных больше не соответствует версии 1.0, первая версия теперь мертв из-за этого, и возникает ошибка. Я хочу, чтобы мой клиент все еще мог использовать версию 1.0. Как я мог/должен был создать приложение для продолжения использования V1?

РЕДАКТИР EnglishBob:

Я хочу, чтобы мой клиент по-прежнему иметь возможность использовать V1. Скажем, у него есть отдел тестирования, и им необходимо, чтобы иметь возможность использовать их LIVE DB, или у него есть трудности в масштабировании приложения через отделы эффективно, поэтому он должен одновременно работать как v1, так и v2.

источник

2014-08-16 Smithy

Это будет очень сложно. Как известно, ORM плохо обрабатывает изменения схемы. –

Я знаю это, но, конечно, несколько человек попытались и не смогли/преуспели. Мне хотелось бы знать, как это сделать. То есть Layer между ними с API, который всегда является текущим, или способ запустить EF, игнорируя обновленные изменения. – Smithy

Что вы можете сделать: 1. Сначала используйте код и создайте цепочку контекстов diff в цепочке наследования. 2. Определите версию db во время загрузки и загрузите правильный контекст. –

Один из вариантов - это объединение вашей бизнес-логики с помощью RESTFUL Webservices, чтобы клиент не напрямую обращался к базе данных, но только версии данных, возвращаемые службой, и OR-сопоставление происходит на стороне сервера. В RESTFUL Webservices каждое представление объектов идентифицируется специальным uri, например «www.example.com/rest/api/2/posts», где 2 означает «Позжевые представления» версии 2. Представления REST могут отличаться от хранилища целевой объектов в базе данных. На стороне клиента необходим клиент http, чтобы получить представление json или xml, и клиент должен преобразовать его в POCOs. В java с JAXB классы могут быть аннотированы, так что процессы сериализации и десериализации выполняются каркасом. Возможно, .NET также поддерживает такие аннотации. Если новый столбец введен, ваш клиент может его игнорировать, но если столбец удален, изменен или отношения изменены, версия должна быть увеличена до 3, а uri с версией 2 должен вернуть представление, которое уже понимает старый клиент. Я думаю, что без дополнительного слоя на стороне сервера практически невозможно выполнить управление сложными изменениями в базе данных. Одним простым примером может быть пользователь с отношением «один к одному» к адресу, который будет изменен на один на один.

источник

2014-08-16 09:57:34

Спасибо, это то, как я планировал выпустить свое приложение. Вы считали альтернативы и это лучший и/или единственный способ? – Smithy

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

Проблема в том, что клиент ничего не знает о будущих изменениях. Если единственными изменениями будут новые добавленные столбцы, база данных может быть сконструирована с ключом, значением и типом, где ключ - это имя поля, а тип говорит клиенту, в каком типе должно быть задано значение. В android такая концепция используется для ContactsProvider, где могут храниться данные из разных источников данных (см. Отношения с данными в этой ссылке -> http://developer.android.com/guide/topics/providers/contacts-provider.html #DataBasics). –

Лучше всего поддерживать 2 DB, тестовый и производственный. Направьте своего клиента в производственную базу данных и разработайте тестовую версию. После того, как вы отправили V2 на обновление своего клиента, производственная БД и сообщите ему, что V1 теперь устарел.

Я не вижу другого способа обойти это, если схема БД изменилась.

источник

2014-08-16 09:25:09 edge2

Я хочу, чтобы мой клиент все еще мог использовать V1. Скажем, у него есть отдел тестирования, и им нужно иметь возможность использовать их LIVE DB, или он испытывает трудности в масштабировании приложения через отделы эффективно, поэтому должен одновременно работать как v1, так и v2. – Smithy

Спасибо за информацию. Я думаю, что на практике вы найдете поддержку обратной совместимости для предыдущих интерфейсов много хлопот, и это увеличит сложность вашего приложения. Все, что он делает, - это переместить проблему с клиента на сервер для большей работы. Хотя, если это то, что нужно клиенту, я полагаю, что выбора нет, удачи в проекте! :) – edge2

Пятно на @englishbob У меня с трудом возникает проект, к счастью, это только для 1 клиента, но мы смотрим на масштабирование в течение следующих нескольких месяцев. Мне нужно сейчас подготовиться :) – Smithy

Как реализовать управление версиями с Entity Framework

ответ

Смежные вопросы