Я установил VS SP1 и поигрался с Entity Framework.
Я создал схему из существующей базы данных и попробовал несколько основных операций.
По большей части все прошло хорошо, за исключением обновления схемы базы данных.
Я изменил базу данных всеми основными способами:
Первые три прошли хорошо, но изменение типа и удаление столбца не последовало за изменениями в базе данных.
Есть ли способ заставить работать дизайнера? Или на данный момент не поддерживается? Я пока не нашел никаких материалов по теме, но все еще ищу.
Да, сейчас он очень зрелый, с codefirst у меня больше нет этой проблемы.





Я бы предположил, что, возможно, этого не произойдет, потому что они нарушат сборку для существующего кода, но это всего лишь предположение с моей стороны.
Вот моя логика:
Во-первых, предполагается, что EF представляет собой сопоставление таблиц более 1: 1, поэтому вполне возможно, что только то, что вы удаляете столбец из таблицы A, не означает, что для этой сущности не должно быть описания свойства. Вы можете просто сопоставить это свойство с другой таблицей.
Во-вторых, изменение типа может просто нарушить сборку. это единственное объяснение.
Изменение типа может нарушить сборку, но в реальных приложениях такое случается. У RoR или Django для этого есть процедура с чрезвычайно низким трением. Чтобы справиться с «перерывом», вы создаете миграции данных. Если у EF этого нет, то есть, что наверстать.
Судя по демонстрациям дизайнера, который я видел, это не безупречный инструмент. Это продукт версии 1.0, поэтому у него обязательно есть некоторые болевые точки. Похоже, тип изменения - один из них. Наблюдая за дизайнером и генерацией кода, я понял, что один из них сломается либо во время компиляции (маловероятно), либо во время выполнения (когда модель фактически выполняется).
Вам необходимо самостоятельно удалить столбец из дизайнера или XML-файла.
Я обнаружил, что в целом все еще существует довольно много ошибок с функцией «Обновить модель из базы данных».
Ключи - убийца для меня - мне еще не приходилось вносить какие-либо изменения в отношения внешнего ключа или добавлять первичный ключ в таблицу, чтобы программа обновления работала правильно (в том смысле, что она выдаст ошибку компиляции на сгенерированном code) - но для решения проблемы достаточно просто удалить модель и повторно импортировать (занимает всего минуту) - это явно не идеально, но у меня никогда не было сбоев из-за «свежего» импорта.
Было так неправильно удалять и начинать заново ... но я думаю, что я не единственный человек, которому пришлось прибегнуть к этому!
Как упоминалось ранее, вы можете просто удалить столбец из дизайнера. Что касается изменения типа данных столбца: просто обновите модель из базы данных, затем перейдите к сопоставлениям таблиц и выберите столбец, который вы изменили в БД. значения справа представляют вашу модель, как ни странно, это не обновляется автоматически, а просто выберите столбец справа, перейдите к свойствам и измените тип данных там. Оно должно стать выпадающим меню.
Ваше здоровье.
Рудди
Я создал подобное приложение, как вы просили. Но мое решение было слишком трудным. Я постараюсь рассказать;
Вы должны создать свои собственные классы управления базой данных, и эти объекты будут отвечать за создание, обновление схемы базы данных (я создал это вручную).
Я видел хорошую статью и исходный код на Блог команды ADO.NET, тогда вы также можете скачать EDMTools из этого блога, он с открытым исходным кодом. И вы также можете внедрить процедуры генерации модели и обновления из этого в свой проект.
Наконец, когда ваша схема изменилась, вы должны воссоздать и привязать свою модель и перестроить сборку данных во время выполнения. Но вы должны знать, что самое важное, вы должны связать свою сборку модели данных со своим проектом с помощью слабосвязанных (ознакомьтесь с этим почтовый)
В противном случае вам следует дождаться выпуска EF 4.0 (сейчас это CTP 1), они объявили, что будут предоставлять функции создания, удаления и обновления DatabaseScript.
Хороший замок
Я делаю это (и делаю все, что вы упомянули, а также переименовываю столбцы) путем внесения изменений в базу данных и регенерации кода EF с использованием EF Code First.
Я не изменяю классы EF Code First ни в лучшую, ни в плохую сторону (включая столбцы с бессмысленными именами для отношений), чтобы упростить процесс.
Ни один дизайнер или генератор схемы ORM не сможет вносить изменения в вашу производственную базу данных, если в ней есть ограниченные данные. Вот почему вы всегда должны начинать с проверки, возможны ли ваши изменения в БД, пробовать их в базе данных разработки, а затем адаптировать свой код для отражения изменений.
Отличный вопрос. Была такая же проблема недавно и пару лет назад. :-) Пожалуй, стоит упомянуть, что переименование существующего столбца могло вызвать головную боль.