2013-02-08 2 views
1

Так что проблема, которую я пытаюсь решить, заключается в следующем: Мы используем Entity Framework для доступа к нашей базе данных Oracle, которая имеет 1200-1500 таблиц. Теперь помните, что мы не обращаемся ко всем, но, возможно, возможно, к 800+ к доступу. Мы используем шаблон UnitOfWork -> Repository -> Service, и это отлично работает, но мы пытаемся выяснить, есть ли у нас один большой DbContext или несколько небольших контекстов, характерных для этой задачи.Контексты UnitOfWork и Entity Framework

Наша UnitOfWork является установка с помощью EFUnitOfWorkBase так:

public abstract class EFUnitOfWorkBase : IUnitOfWork 
{ 
    private bool isDisposed = false; 

    public DbContextBase Context { get; set; } 

    protected EFUnitOfWorkBase(DbContextBase context) 
    { 
     Context = context; 
    } 

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

    public void Dispose() 
    { 
     if (!isDisposed) 
      Dispose(true); 
     GC.SuppressFinalize(this); 
    } 

    private void Dispose(bool disposing) 
    { 
     isDisposed = true; 
     if (disposing) 
     { 
      if (this.Context != null) 
       this.Context.Dispose(); 
     } 
    } 

    public IRepository<TEntity> GetRepository<TEntity>() where TEntity : Common.EntityBase<TEntity> 
    { 
     return new Repository<TEntity>(this); 
    } 
} 

Любая единица работы, которую мы создаем расширяет что база одна и обеспечивает контекст, как так:

public class EmployeeDirectoryUnitOfWork : EFUnitOfWorkBase 
{ 
    public EmployeeDirectoryUnitOfWork(string connectionString) 
     : base(new EmployeeDirectoryContext(connectionString)) 
    { 
    } 
} 

DbContext передается строка подключения через единицу работы.

Repository выглядит следующим образом:

public abstract class RepositoryBase<TEntity> : IRepository<TEntity> where TEntity : class 
{ 
    protected DbContextBase Context; 
    protected DbSet<TEntity> EntitySet; 

    public RepositoryBase(EFUnitOfWorkBase unitOfWork) 
    { 
     Enforce.ArgumentNotNull(unitOfWork, "unitOfWork"); 

     Context = unitOfWork.Context; 
     EntitySet = Context.Set<TEntity>(); 
    } 

    public TEntity Add(TEntity entity) 
    { 
     Enforce.ArgumentNotNull(entity, "entity"); 

     return EntitySet.Add(entity); 
    } 

    public TEntity Attach(TEntity entity) 
    { 
     Enforce.ArgumentNotNull(entity, "entity"); 

     return EntitySet.Attach(entity); 
    } 

    public TEntity Delete(TEntity entity) 
    { 
     Enforce.ArgumentNotNull(entity, "entity"); 

     return EntitySet.Remove(entity); 
    } 

    public System.Linq.IQueryable<TEntity> Query() 
    { 
     return EntitySet.AsQueryable(); 
    } 

    public TEntity Save(TEntity entity) 
    { 
     Enforce.ArgumentNotNull(entity, "entity"); 

     Attach(entity); 
     Context.MarkModified(entity); 

     return entity; 
    } 
} 

Любые предложения о том, как лучше справиться с этой ситуацией?

ответ

7

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

Для получения более подробной информации, Джулия Лерман недавно выступила с курсом по Pluralsight о Entity Framework на предприятии, который действительно хорош. Она опубликовала небольшой клип (фактически об ограниченном контексте) на this site. Это очень хороший курс, и я очень рекомендую его, особенно для того, что вы делаете.

+1

+1 для справки Julie Lerman. Она босс EF! –

+1

... и остальная часть вашего совета тоже очень звучит :) –

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