Архитектура, так что вы можете поменять структуру сущностей на SQL и наоборот - PullRequest
Новая
       31

Архитектура, так что вы можете поменять структуру сущностей на SQL и наоборот

0 голосов
/ 16 сентября 2011

Я боролся с этим уже какое-то время. Если вы делаете архитектуру, как это .. 

Project.Domain
- Entities
- Repositories interfaces Project.Persistence.EF
- Repositories
- ContextProvider
- etc.. 
Project.Persistence.SQL 
??? 
Project.Tasks 
... 
Project.Presentation 
...

С IoC вы можете почти изменить любые компоненты для других компонентов. Важным интерфейсом, который здесь связан с вопросом, является IRepository (Generic), расположенный в домене. Это только определение, а не реализация.

Основная проблема, на которую я смотрел, это Как я могу переключить EF для SQL почти мгновенно?

Если вы посмотрите на интерфейс репозитория ... он явно предназначен для работы с контекстом. 

public interface IRepository<T> where T : class
{
    void Add(T entity);
    void Delete(T entity);
    T GetById(long Id);
}

Как я могу затем заставить этот репозиторий работать также с реализацией SQL, чтобы я мог использовать IoC для выбора между EF и SQL?

Конечно, я мог бы создать IRepositorySQL и IRepositoryEF, но тогда я не смог бы использовать IoC для этого ... и я снова застрял.

Любые идеи или предложения или способ сделать вещи?

Спасибо.

1 Ответ

3 голосов
/ 16 сентября 2011

Главное при абстрагировании уровня данных до универсального решения - отбросить все специфические особенности:

  • Вы отбросите LINQ, потому что это специфическая особенность некоторого ORM
  • Youбудет отбрасывать отложенную загрузку, потому что она специфична для некоторого ORM
  • Вы отбросите отслеживание изменений или реализуете собственное отслеживание изменений
  • и т. д.

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

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

Из-за этого это следует делать только в случае крайней необходимости = это один из основных продуктов.требования.В противном случае это трата времени и денег .

...