2012-03-31 2 views
0

Я работаю над проектом, который использует Linq2SQL для доступа к данным. Проект состоит из приложения ASP.NET MVC и 8 библиотек классов. Большинство библиотек классов имеют свои классы данных L2S.Как абстрагироваться Linq2SQL для проверки?

Как часть работы, которую я выполняю, я пытаюсь получить различные тестируемые компоненты, чтобы обеспечить некоторую стабильность очистки базы кода, в настоящее время она активно использует статические классы и методы, а контроллеры имеют статические DataContexts, которые используются повсюду.

Как я могу реорганизовать использование L2S, чтобы проверить действия контроллера?

Я ввел инъекцию зависимостей в приложение, чтобы отделить некоторые из других сервисов, но я не хочу, чтобы DataContext был свойством зависимостей контроллеров, потому что я хочу контролировать создание экземпляров DataContexts и их DataLoadOptions.

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

ответ

3

Я использую шаблон хранилища, чтобы скрыть DataContext внутри. Хранилища - это абстракции, поэтому люкс действительно хорош с принципом Injection Dependency.

Например, вы определяете некоторый репозиторий.

public interface IUserRepository 
{ 
    User Get(int id); 
    User Save(User user); 
    void Delete(User user); 
} 

Реализация нечто вроде

public class UserRepository : IUserRepository 
{ 
    private MyDataContext _context; 

    UserRepository() 
    { 
     _context = new MyDataContext(); 
    } 

    // ... 

} 

Теперь контроллер зависит только от интерфейса.

public UserController : Controller 
{ 
    UserController(IUserRepository userRepository) { } 
} 

Таким образом, это совершенно проверяемых, так как вы можете издеваться IUserRepository в ваших тестах.

+0

Это будет абстрагироваться над LINQ to SQL, но оно также удалит все его функции. С помощью этой схемы мы вернемся к типизированным наборам данных. – usr

+0

@usr - я так не думаю .. –

+0

Я не вижу способа выполнения запросов. Самые интересные приложения требуют запросов, которые делают больше, чем фильтр и порядок. Вам нужен общий запрос. – usr

1

В то время как this article относится к тестируемости использования структуры сущности, здесь может быть применена концепция высокого уровня.

Сердце контуров примеров с использованием шаблона «Единица работы» с шаблоном «Репозиторий». Блок работы представляет собой абстракцию вокруг контекста данных и представляет собой рабочий набор для конкретного контроллера или набор аналогичных контроллеров. Вы можете включить несколько репозиториев в устройство, и поскольку хранилища основаны на IEnumerable или IQueryable, вы все равно можете воспользоваться функциональностью LINQ.

Варианты тестирования включают издевательство над Единицей и Хранилищами или создание представлений в памяти для целей тестирования.

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