Entity Framework на .mdf файл

Я работаю над некоторым проектом на данный момент, и мне нужно использовать локальную базу данных. Итак, я создал новую сервисную базу данных (нет таблиц atm). Затем я хотел добавить поддержку Entity Framework.Entity Framework на .mdf файл

Поскольку я никогда раньше не использовал Entity Framework, я имел в виду эту ссылку: http://msdn.microsoft.com/en-us/data/jj200620.aspx.

Все в порядке, но здесь это осложняется. Я создал свой класс DataContext с DbSet внутри него. Но, когда я запускаю свой модульный тест, таблица создается на Localdb (не внутри моего файла).

Что делать?

Я уверен, что я выбрал, какую базу данных использовать правильно (на самом деле это уже 3 раза), но все же таблицы данных создаются на LocalDb. Что я здесь делаю неправильно?

Я полный новичок с этим (использовал только доктрину ORM). В противном случае я могу вставить данные и все, это просто неправильная база данных.

источник

2014-10-04 Orochi

Является ли ваш блок тестированием в отдельном проекте с другим app.config? Это, похоже, связано с проблемой строки подключения. – Ofiris

Да, это так. Но я также скопировал тот же app.config, который я использую внутри проекта DataAccess в этом проекте UnitTest. – Orochi

Вы используете код первым? – shawty

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

Один из конструкторов (из которых имеется довольно много перегрузок) в родительских классах контекста EF Data, принимает простую строку.

Эта строка указывается как имя строки подключения в используемой конфигурации приложения или сети.

Вы делаете звонок что-то вроде этого:

using System.Data.Entity; 

namespace MSSQL_EFCF.Classes 
{ 
    public class DataAccess : DbContext 
    { 
    public DataAccess() : base("myConnectionString") 
    {} 

    public DbSet<MyTableObject> MyObjects { get; set; } 

    } 
}

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

Преимущество в этом случае заставляет сущность framework всегда использовать именованную строку соединения и никогда ничего.

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

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

В моем примере выше, EF изучит приложение и/или Web.config для строки соединения под названием «myConnectionString»

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

Я ранее написал сообщение в блоге на эту тему, которую вы можете найти здесь:

http://www.codeguru.com/columns/dotnet/entity-framework-code-first-simplicity.htm

ПРИМЕЧАНИЕ: Вышесказанное относится к любой базе данных, который подключается с помощью EF, это строка подключения, которая определяет, где/где находится фактическое хранилище данных.

источник

2014-10-04 18:18:06 shawty

Entity Framework на .mdf файл

ответ

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