Методы репозитория по сравнению с расширением IQueryable

Как был указан, Вы не можете программно открыться управление всем стилем сами. Что-то как то, что Вы видите критерии поиска автоматического заполнения на Yahoo! Google или или Поиск поля Location в Погодная Сеть .

я нашел один для jQuery здесь . Я понятия не имею, удовлетворило ли это Ваши потребности, но даже если бы это не полностью удовлетворяет Ваши потребности, должно быть возможно изменить его так, это открылось бы как результат некоторого другого действия или события. Этот на самом деле более многообещающие взгляды.

33
задан svick 15 February 2012 в 01:27
поделиться

2 ответа

@Alex - я знаю, что это старый вопрос, но я бы позволил Репозиторию делать только действительно простые вещи . Это означает получение всех записей для таблицы или представления.

Затем на уровне СЛУЖБЫ (вы используете n-уровневое решение, не так ли? :)) я бы обрабатывал там все «специальные» запросы.

Хорошо, время для примера.

Уровень репозитория

ContactRepository.cs

public IQueryable<Contact> GetContacts()
{
    return (from q in SqlContext.Contacts
            select q).AsQueryable();
}

Красиво и просто. SqlContext - это экземпляр вашего EF Context .., в котором есть Entity под названием Contacts .. который в основном является вашими контактами sql класс.

Это означает, что этот метод в основном выполняет: SELECT * FROM CONTACTS ... но он не попадает в базу данных с этим запросом ... сейчас это всего лишь запрос.

Хорошо .. следующий слой .. УДАР ...вверх поехали ( Начало кто-нибудь?)

Уровень служб

ContactService.cs

public  ICollection<Contact> FindContacts(string name)
{
    return FindContacts(name, null)
}

public ICollection<Contact> FindContacts(string name, int? year)
{
   IQueryable<Contact> query = _contactRepository.GetContacts();

   if (!string.IsNullOrEmpty(name))
   {
       query = from q in query
               where q.FirstName.StartsWith(name)
               select q;
   }

   if (int.HasValue)
   {
       query = from q in query
               where q.Birthday.Year <= year.Value
               select q);
    }

    return (from q in query
            select q).ToList();
}

Готово.

Итак, подведем итоги. Сначала мы начнем с простого запроса « Получить все из контактов ». Теперь, если у нас есть имя, давайте добавим фильтр для фильтрации всех контактов по имени. Затем, если у нас есть год, мы фильтруем день рождения по Year. И т.д. Наконец, мы обращаемся к БД (с этим измененным запросом) и смотрим, какие результаты мы получим.

ПРИМЕЧАНИЯ: -

  • Я пропустил внедрение зависимостей для простоты. Это более чем настоятельно рекомендуется.
  • Это все псевдокод. Не тестировалось (против компилятора), но идея понятна ....

Выводы

  • Уровень служб обрабатывает все умные функции. Именно здесь вы решаете, какие данные вам требуются.
  • Репозиторий - это простой SELECT * FROM TABLE или простой INSERT / UPDATE в TABLE.

Удачи :)

7
ответ дан 27 November 2019 в 19:33
поделиться

Я много думал об этом в последнее время, начиная с моей нынешней работы. Я привык к репозиториям, они проходят полный путь IQueryable, используя только голые репозитории, как вы предлагаете.

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

Есть ли, возможно, способы переосмыслить, почему вы запрашиваете данные так разными способами? Если нет, то я действительно считаю, что гибридный подход - лучший вариант. Создайте методы репо для вещей, которые вы повторно используете. Вещи, для которых это действительно имеет смысл. СУХОЙ и все такое. Но эти одноразовые? Почему бы не воспользоваться IQueryable и другими сексуальными вещами, которые с его помощью можно делать? Как вы сказали, это глупо, создать для этого метод, но это не значит, что вам не нужны данные. DRY действительно не применяется, не так ли?

Чтобы сделать это хорошо, потребуется дисциплина, но я действительно думаю, что это правильный путь.

12
ответ дан 27 November 2019 в 19:33
поделиться