Entity framework 6 предоставляет репозитории и UoW из коробки

Question

Но как вы его используете?

У меня есть проект Code First, и вы можете попробовать что-то в этом новом EF6. Чтение всех видов сообщений/блогов от не менее 2-х лет о EF4/5. Но ничего особенного в EF6.

Скажем, у меня есть эти сущности:

public DbSet<Person> Persons { get; set; } 
public DbSet<Order> Orders { get; set; } 
public DbSet<Invoice> Invoices { get; set; } 

ли мне еще нужно создавать репозитории для каждого объекта? Или можно было бы использовать class с некоторыми методами для выполнения некоторых пользовательских вычислений, кроме CRUD?

Я знаю, что эта линия:

kernel.Bind<MyDbContext>().ToSelf().InRequestScope(); 

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

Проект имеет библиотеку классов и веб-проект asp.net-mvc. Если проект класса lib содержит мои объекты и включен Migrations.

Любой свет по этому вопросу действительно оценен.

Answer 1

Я добавил слой репозитория поверх EF (который использует как репозиторий, так и шаблоны UoW по своей конструкции) в нескольких проектах, и я сделал это с одним классом, который использует дженерики, чтобы я Мне нужен только один файл для всех моих объектов. Вы можете решить, хотите ли вы это сделать или нет, но я нашел его полезным в своих проектах.

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

public class Repository<T> : IRepository<T> where T : class 
{ 
    protected IDbContext Context; 
    protected DbSet<T> DbSet { get { return Context.Set<T>(); } } 

    public Repository(IDbContext context = null) 
    { 
     Context = context ?? new DbContext(); 
    } 

    public void Add(T newRecord) 
    { 
     DbSet.Add(newRecord); 
    } 

    public void Update(T record) 
    { 
     var entry = Context.Entry(record); 
     DbSet.Attach(record); 
     entry.State = EntityState.Modified; 
    } 

    public void Remove(T record) 
    { 
     Context.Entry(record).State = EntityState.Deleted; 
     DbSet.Remove(record); 
    } 

    public IQueryable<T> Where(Expression<Func<T, bool>> predicate) 
    { 
     return DbSet.Where(predicate); 
    } 

    public bool Contains(Expression<Func<T, bool>> predicate) 
    { 
     return DbSet.Count(predicate) > 0; 
    } 

    public int Count(Expression<Func<T, bool>> predicate) 
    { 
     return DbSet.Count(predicate); 
    } 

    public int Save() 
    { 
     return Context.SaveChanges(); 
    } 
} 

я использовал хранилищами 2 основных причин:

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

2. Расширяемость. Целый ряд раз я использовал некоторые методы в моем репозитории, потому что обнаружил, что постоянно выполняю ту же логику с запросами в своих контроллерах. Это было чрезвычайно полезно, особенно потому, что ваш код на стороне клиента не должен знать, как он это делает, просто он делает это (что упростит вам, если вам нужно изменить логику одного файла или нескольких файлов).

Это не все, очевидно, но этого должно быть достаточно для этого ответа. Если вы хотите узнать больше на эту тему, я написал на нем сообщение в блоге, которое вы can find here.

Удачи вам в том, что вы решите сделать.

Answer 2

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

Если вы хотите, чтобы построить еще один Repository на вершине, что EF обеспечивает, это полностью зависит от вас - или бизнес-правил.

Многие сложные проекты используют 2-3 слоя репозиториев с веб-сервисами между ними. Производительность ниже, но вы выигрываете в других планах, таких как безопасность, устойчивость, разделение концертов и т. Д.

Ваша компания может решить, что в их интересах никогда не получать доступ к данным непосредственно из проектов front-end. Они могут заставить вас построить отдельный проект веб-сервиса, который будет доступен только с localhost. Таким образом, вы получите EF как Репозиторий в проекте webservice. На стороне входа вам, очевидно, потребуется построить еще один репозиторий, который будет работать с веб-сервисом.

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

Чтобы быть политически корректным, я в том числе замечание, высказанное Wiktor Zychla:
". DbSet является хранилищем и DbContext является единица работы„Entity Framework является Repository“может привести к ненужной путанице."