Entity Framework, Обновление

У меня большие проблемы с Entity Framework (4.0) из-за шаблона «добавления» в программу. (с использованием ASP.NET MVC)

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

Кто-нибудь знает какие-либо лучшие инструменты или методы для такого рода проблем?


asp.net-mvc entity-framework-4
person Ciel    schedule 16.07.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Хорошо, возьми два. Похоже, что вместо использования конструктора вам лучше пойти по маршруту «сначала код» и использовать аннотации данных.

Аннотации данных: http://blogs.msdn.com/b/efdesign/archive/2010/03/30/data-annotations-in-the-entity-framework-and-code-first.aspx -- Проверьте storeNameAttribute для конкретного случая, который вы упомянули в комментарии к моему удаленному ответу.

Хорошая запись кода здесь: http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx

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

person heisenberg    schedule 16.07.2010
comment
Новый код впервые был выпущен пару дней назад: hanselman.com/blog/ - person John Farrell; 16.07.2010
comment
Да, это тот же ctp, на который я ссылаюсь в ссылке ScottGu, которую я разместил. - person heisenberg; 16.07.2010
comment
Ой, не заметил, что вы разместили ту же ссылку. - person John Farrell; 16.07.2010
comment
Да, я смотрю на это. Но это больше похоже на «создание» базы данных; Это не то, что нам нужно делать. Нам просто нужно сначала отобразить с помощью кода. Но ни один из этих примеров не объясняет этого... вообще. - person Ciel; 16.07.2010
comment
Нет, он работает и с уже существующей базой данных. Суть в том, что это способ убрать из уравнения дизайнера и разработчика кода. - person heisenberg; 16.07.2010
comment
Эти примеры очень разочаровывают... как будто они просто не заботятся о том, чтобы цитировать что-либо, кроме одного и того же трижды. Есть ли место, где я могу просто СКАЗАТЬ использовать существующую базу данных? Это все, что я хочу. Я не хочу, чтобы он создавал мой. - person Ciel; 16.07.2010
comment
По умолчанию он не будет создавать новый, если указанный вами не существует. - person heisenberg; 16.07.2010
comment
Где указать один? Вот что сводит меня с ума. Я не могу найти никакого метода или конструктора, который принимает любой способ указать, какую базу данных использовать. - person Ciel; 16.07.2010
comment
ConnectionStrings в вашем файле конфигурации, по умолчанию он будет искать connectionString с тем же именем, что и ваш DbContext. - person heisenberg; 16.07.2010
comment
Спасибо! Почему ни один из этих людей, пишущих образцы, не может потратить десять секунд, чтобы прямо заявить об этом? Кажется, что это чрезвычайно важная вещь, на которую стоит обратить внимание. Есть ли способ указать КОНКРЕТНУЮ строку подключения для просмотра? - person Ciel; 16.07.2010
comment
Есть ли способ конкретно сказать, чтобы он никогда не пытался «создать» базу данных? - person Ciel; 16.07.2010
comment
@Stacey Когда-нибудь пробовали читать документацию MSDN? msdn.microsoft.com/en-us/ библиотека/ - person John Farrell; 16.07.2010
comment
Да, за исключением того, что ObjectContext здесь не используется, поэтому документация для него, как правило, бесполезна, и я не смог найти запись для DbContext. - person Ciel; 16.07.2010
comment
Есть ли способ указать КОНКРЕТНУЮ строку подключения для просмотра? Тьфу, я только что понял, что атрибут DataAnnotations, который, как я думал, может справиться с этим, сейчас находится на стадии предложено. Действительно немного удивлен, что они не встроили эту возможность с самого начала, сейчас копаются, чтобы попытаться найти способ заставить это работать (я думаю, что EF fluent API делает это возможным, но это выглядит громоздко, пытаясь понять какой-то метод, управляемый конфигурацией) - person heisenberg; 16.07.2010
comment
Я делал некоторую работу, и у меня есть немного более умеренный успех. Я довольно неоднозначно отношусь ко всему этому методу; Слишком уж похоже, что они пытаются сделать что-то не то с помощью модели «беглого» кода. - person Ciel; 17.07.2010
comment
@Stacey - Сегодня было опубликовано еще кое-что по делу... weblogs.asp.net/scottgu/archive/2010/07/23/ - person heisenberg; 24.07.2010
comment
Ах, очевидно, вы можете передать строку в конструктор контекста, чтобы указать ему, какое имя искать в app.config. - person heisenberg; 27.07.2010

arrow_upward
0
arrow_downward

Что ты делал раньше? Вы провели рефакторинг базы данных и НЕ должны были изменить код?

До сих пор я использовал все, от ADO.NET до трех .NET ORM (Nhibernate, Linq2Sql и Entity Framework), баловался Django и Python, а теперь увлекаюсь Ruby on Rails. Ни один из этих инструментов не решил полностью проблему несоответствия импеданса между базой данных и кодом.

Где-то где-то должен существовать этот код:

DBCOLUMN => CODE //or
myModel.Property = rdr["something"]  //or
<Property Name="EndDate" Type="datetime" /> //or
Id(x => x.Id);

Будь то представление Rails, файл миграции, дизайнер Linq2Sql или файл Fluent Nhibernate, не имеет значения. Это всегда будет проблемой.

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

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

person John Farrell    schedule 16.07.2010