Невозможно начать удаленный сеанс

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

Mockable Repository для Unit Tests,

Мы позволяем EF общаться для тестирования БД в модульных тестах, чтобы протестировать нашу бизнес-логику прямо против тестовой БД SQL. Я не вижу никакой пользы от макета какого-либо шаблона репозитория. Что действительно не так делает модульные тесты против тестовой базы данных? Поскольку это массовые операции невозможны, и мы заканчиваем тем, что пишем исходный SQL. SQLite в памяти является идеальным кандидатом для проведения модульных тестов с реальной базой данных.

Ненужная абстракция

Вы хотите создать репозиторий так, чтобы в будущем вы могли легко заменить EF на NHbibernate и т. Д. Или что-нибудь еще?

Linq убивает юнит-тесты?

Мне понравятся любые примеры того, как это можно убить.

Injection Dependency, IoC

Ничего себе, это отличные слова, они отлично смотрятся в теории, но иногда вам приходится выбирать компромисс между отличным дизайном и отличным решением. Мы все это использовали, и мы закончили тем, что бросали все на мусор и выбирали другой подход. Размер против скорости (размер кода и скорость разработки) имеет огромное значение в реальной жизни. Пользователям нужна гибкость, им все равно, будет ли ваш код великолепным в дизайне с точки зрения DI или IoC.

Если вы не создаете Visual Studio

Все эти великолепные дизайны необходимы, если вы создаете сложную программу, такую ​​как Visual Studio или Eclipse, которая будет разработана многими людьми, и она должна быть очень настраиваемой. Все большие модели развития вступили в картину после многих лет развития, которые прошли эти IDE, и они эволюционировали на месте, где все эти большие шаблоны дизайна имеют большое значение. Но если вы делаете простую веб-заработную плату или простое деловое приложение, вам лучше развиваться в вашем развитии со временем, а не тратить время на его создание для миллионов пользователей, где он будет развернут только для 100 пользователей.

Репозиторий как фильтрованный вид - ISecureRepository

С другой стороны, репозиторий должен быть фильтрованным представлением EF, который защищает доступ к данным, применяя необходимый наполнитель на основе текущего пользователя / роли.

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

Следующий ответ представляет собой пример реализации Filtered Repository без создания всего набора классов и методов. Он может не отвечать на вопрос напрямую, но может быть полезным при его получении.

Отказ от ответственности: я являюсь автором Entity REST SDK.

http: //entityrestsdk.codeplex. com

Учитывая вышеизложенное, мы разработали SDK, который создает репозиторий фильтрованного представления на основе SecurityContext, который содержит фильтры для операций CRUD. И только два типа правил упрощают любые сложные операции. Первый - это доступ к сущности, а другой - правило чтения / записи для свойства.

Преимущество заключается в том, что вы не переписываете бизнес-логику или репозитории для разных типов пользователей, просто просто блокируете или предоставляете им доступ ,

public class DefaultSecurityContext : BaseSecurityContext {

  public static DefaultSecurityContext Instance = new DefaultSecurityContext();

  // UserID for currently logged in User
  public static long UserID{
       get{
             return long.Parse( HttpContext.Current.User.Identity.Name );
       }
  }

  public DefaultSecurityContext(){
  }

  protected override void OnCreate(){

        // User can access his own Account only
        var acc = CreateRules();

        acc.SetRead( y => x=> x.AccountID == UserID ) ;
        acc.SetWrite( y => x=> x.AccountID == UserID );

        // User can only modify AccountName and EmailAddress fields
        acc.SetProperties( SecurityRules.ReadWrite, 
              x => x.AccountName,
              x => x.EmailAddress);

        // User can read AccountType field
        acc.SetProperties( SecurityRules.Read, 
              x => x.AccountType);

        // User can access his own Orders only
        var order = CreateRules();
        order.SetRead( y => x => x.CustomerID == UserID );

        // User can modify Order only if OrderStatus is not complete
        order.SetWrite( y => x => x.CustomerID == UserID 
            && x.OrderStatus != "Complete" );

        // User can only modify OrderNotes and OrderStatus
        order.SetProperties( SecurityRules.ReadWrite, 
              x => x.OrderNotes,
              x => x.OrderStatus );

        // User can not delete orders
        order.SetDelete(order.NotSupportedRule);
  }
}

Эти правила LINQ оцениваются по методу SaveChanges для базы данных для каждой операции, и эти правила действуют как брандмауэр перед базой данных.