Дразнящая NHibernate & Linq

Question

Я использую NHibernate и выставил сессию в моем интерфейсе.У меня есть действие контроллера, которое извлекает задачи следующим образом:

public ActionResult Overview(DateTime date)
{
    var allTasks = GetTasksUpUntilDate(date);
    return PartialView("Tasks/Overview", allTasks);
}

private List<TaskOverviewModel> GetTasksUpUntilDate(DateTime date)
{            
    var allTasks = _session.Query<Task>().Where(t.BookedBy.UserName.Equals(CurrentUser.Name,
                                       StringComparison.CurrentCultureIgnoreCase));            
    var tasks = allTasks.Where(t => t.DueDate <= date);

    var taskVMs = new List<TaskOverviewModel>();        
    tasks.ForEach(t => taskVMs.Add(MapEntityToViewModel(t)));

    return taskVMs;
}

Теперь я не хочу создавать IRepository только для моих представлений, поскольку ISession фактически уже является хранилищем.Насмешка / огрызание это, однако, оказывается довольно сложно.Так может ли кто-нибудь помочь мне получить _session.Query вернуть список объектов, которые я предоставляю во время тестирования?.

Я также хотел бы избежать настройки базы данных в памяти и использую RhinoMocks для своих тестов.

Answer 1

Не подделка Nh / linq.Вместо этого установите sqlite db в памяти для запроса.Они чрезвычайно быстры и просты в использовании.

Answer 2

NHibernate Session может соответствовать шаблону репозитория, но если вы строите свои контроллеры для непосредственного взаимодействия с ним, вы не будете по-настоящему абстрагировать его. Дразнить, когда ты не абстрагируешься, это не надежное решение.

Если вы абсолютно не хотите абстрагировать его (что является чисто ленивым, IMO), то sqllite db, как упомянуто Джейсоном, - хороший вызов. Тем не менее, в большом проекте правильное разделение ваших интересов - очень хорошая идея.

Модель моего домена содержит интерфейсы как для объектов доступа к данным (репозитории), так и для служб, которые их используют. Это позволяет мне действительно отделить свои проблемы с данными от своих бизнес-задач, которые должны быть полностью отделены от проблем представления / приложения. Это позволяет проводить надлежащее модульное тестирование, а также легко заменять детали или производить надлежащую насмешку.

Каждый уровень говорит ТОЛЬКО с интерфейсами, НИКОГДА с реализацией. Кроме того, мой прикладной уровень никогда не взаимодействует напрямую с сервисами уровня данных. То, что это происходит, поощряет разработчиков быть ленивыми и начинать использовать в приложении бизнес-логику или логику данных.