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

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

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 для этого... и я снова застрял.

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

Спасибо.


sql-server asp.net-mvc-3 inversion-of-control ddd-repositories entity-framework-4.1
person Rushino    schedule 16.09.2011    source источник
comment
Вы действительно должны определиться со своим подходом, а затем придерживаться его, очень мало смысла в переключении между встроенным SQL или использованием ORM.   -  person Kane    schedule 16.09.2011
comment
Что вы имеете в виду, говоря, что он предназначен для работы с контекстом? Я не вижу ссылки в IRepository<T>, которая требует какого-либо контекста...   -  person Mark Seemann    schedule 16.09.2011
comment
Не неправильно. Это потому, что я пытаюсь найти решение, в котором вы могли бы быть действительно гибкими, но я думаю, что упустил суть.   -  person Rushino    schedule 16.09.2011
comment
@Mark Seemann Ну, это из-за методов. Вы не можете обновить с помощью SQL. Там только Добавить и Удалить. Автоматическое отслеживание EF изменяется, а SQL — нет.   -  person Rushino    schedule 16.09.2011
comment
Но у вас нет метода Update...   -  person Mark Seemann    schedule 16.09.2011
comment
@Марк Зееманн, я знаю. Вот почему он предназначен для использования с EF.. потому что у него нет метода обновления. В EF вам не нужен метод обновления, так зачем включать его в репозиторий? Объекты отслеживаются.   -  person Rushino    schedule 16.09.2011

Ответы (1)


arrow_upward
3
arrow_downward

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

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

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

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

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

person Ladislav Mrnka    schedule 16.09.2011
comment
+1 Доступ к данным является частью архитектуры. Если вам нужно изменить доступ к данным, вам нужно изменить архитектуру. - person Kristof Claes; 16.09.2011