Основные вопросы Entity Framework - PullRequest
1 голос
/ 13 марта 2012

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

При работе с SQL 2008, VS2010 архитектура папок выглядит следующим образом:

ABC.Domain.Abstract
ABC.Domain.Concrete
ABC.Domain.Concrete.ORM
ABC.Domain.Entities

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

Однако! Я ни разу не убедил обманчиво простой класс EfDbContext: DbContext с методом для работы ...

public DbSet<ABC.Domain.Entities.Person> Person { get { return _context.Persons; }}

Он жалуется на отсутствие ключей, то, что Person не является классом сущности, что он не может найти концептуальную модель и так далее.

  1. Учитывая, что у меня есть базовая строка подключения в web.config, почему бы не создать модель на лету для простого сопоставления?

  2. Должна ли существовать папка ORM или она должна быть бетонной? (У меня есть подпапка .SQL для конкретного LINQtoSQL, поэтому мне подходит .ORM, но если это недостаток, давайте исправим это).

  3. Должны ли я иметь свои домотканые сущности И автоматически созданные или только один набор? Автоматические наследуют от EntityObject, мои просто POCO или POCO с complexTypes, но не наследуют от чего-либо.

  4. Что связывает домашний разработанный тип Domain.Entities.Person со свойством Persons контекста? Книга Сандерсона подразумевает, что сопоставление неявно, если свойства идентичны, какими они есть, но это не делает.

  5. В app.config есть строка подключения со вкусом EF, в файле web.config есть обычная строка подключения. Что я должен использовать - предполагая, что web.config на данный момент - поэтому я должен удалить app.config?

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

Ответы [ 4 ]

1 голос
/ 13 марта 2012

Что связывает домашний разработанный тип Domain.Entities.Person со свойством Persons контекста?

Похоже, у вас возникло недопонимание.Объекты вашего домена являются объектами для базы данных.Там нет двух комплектов.Если вы действительно хотите иметь два набора классов объектов (по какой-либо причине), вы должны написать любое сопоставление между ними вручную.EF знает только о классах, которые являются частью сущностной модели.

Вам также следует - если вы используете EF 4.3 - применять шаблон DbContext Generator T4 к файлу EDMX.Не работайте с EntityObject производными сущностями!Не поддерживается с DbContext.Генератор создаст набор классов POCO и подготовит производное DbContext.Этот набор классов POCO - это объекты, о которых будет знать только DbContext, и они должны быть вашим единственным набором сущностей домена.

Созданные DbContext будут содержать простые свойства DbSet с автоматическими получателями и установщиками..

public DbSet<Person> People { get; set; }

... и класс Person также будет создан как POCO.

0 голосов
/ 15 марта 2012

Решение того, почему ничего не работает, сначала код ...

... оказалась ссылкой на System.Data.EntityClient в строке подключения, которая должна была прочитать System.Data.SqlClient.

Если эта запись провайдера не была правильной, она не смогла сработать первым кодом.

При обнаружении используемой строки подключения была случайная неправильная запись ключевого слова в подключенияхбыли на выбор - все они были названы правильно - но были в app.config, и 2 места в web.config.С явной ошибкой именования, когда приложение выдало ошибку, пытаясь создать модель домена, было легко определить, какую строку подключения использовал мой производный класс DbContext.Исправление ProviderName имело все значение.

Code-first теперь работает просто отлично, с измененными значениями при изменении модели.

0 голосов
/ 13 марта 2012

Здесь много вопросов, и вы не получите ответа, но я выложу свои 5 пенсов за то, что оно стоит.

Книга Сандерсона MVC3

Ваши проблемы связаны не с MVC3, а с Entity Framework и уровнем персистентности данных.

ABC.Domain.Abstract ABC.Domain.Concrete ABC.Domain.Concrete.ORM ABC.Domain.Entities

Можете ли вы сказать, почему это разделено в такойпуть?Я бы поспорил и сказал, что ABC.Domain должен содержать ваши POCO независимо от вашего уровня персистентности (EF) и уровня презентации (MVC).Ваш список подразумевает, что ваш домен содержит ORM и ваши объекты доступа к данным.Я не спорю здесь, я пытаюсь сказать, что вам нужно понять, что вам действительно нужно.

В конце дня я уверен, что достаточно простого примера с ABC.DataAccess, ABC.Domain и ABC.Site.

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

Человек не является классом сущности, он не может найти концептуальную модель и т. Д.

Теперь EF может сохранять данные за вас несколькими способами.Сначала вы можете использовать код, где, как следует из названия, вы сначала напишите код, и EF сгенерирует для вас базу данных, отношения и все соответствующие ограничения.

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

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

Все это может звучать как чёрный ящик, но все, что вы пытаетесь достичь, будет работать.EDMX - хороший способ изучения, и на ASP.Net есть много пошаговых руководств.

, но если это недостаток, давайте исправим это).

Выпридется исправлять и реорганизовывать себя, другого пути улучшения по моему честному мнению нет.Я могу дать вам другую структуру папок / пространств имен, но всегда будет «лучшая».

Должны ли у меня быть мои домотканые сущности И автоматически созданные или только один набор?

Теперь это зависит от выбранной вами модели.Сначала база данных, сначала код, только код и все остальное.Если вы следите за разработкой, управляемой доменом, вам придется работать с классами, которые представляют вашу бизнес-логику и не привязаны к вашему уровню персистентности данных или уровням представления, поэтому POCO - это путь вперед.

Что связывает домашний дизайн типа Domain.Entities.Person с Persons

Теперь это снова зависит от модели, которую вы используете.

app.config и web.config

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

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

Общие советы, пока оставьте MVC в покое.Включите его в консольное приложение и убедитесь, что вы чувствуете себя комфортно с опциями, предлагаемыми в EF.Удачи:)

0 голосов
/ 13 марта 2012

Загрузите инструментальные средства инфраструктуры объектов: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d

Щелкните правой кнопкой мыши в своем проекте, чтобы «перепроектировать существующую базу данных», он создаст классы кода для вас. Нет необходимости использовать EDMX, и этот метод создаст для вас производный класс DbContext

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...