Чи повинні репозиторії повертати IQueryable?

Я бачив багато проектів, у яких є сховища, які повертають екземпляри IQueryable. Це дозволяє додаткові фільтри та сортування можна виконувати IQueryableза іншим кодом, що перекладається на різні генеровані SQL. Мені цікаво, звідки взялася ця закономірність і чи це гарна ідея.

Моя найбільша стурбованість - IQueryableце обіцянка потрапити в базу даних через деякий час, коли вона буде перерахована. Це означає, що помилка буде викинута за межі сховища. Це може означати, що виняток Entity Framework викидається в інший рівень програми.

У минулому я також стикався з проблемами з декількома наборами активних результатів (MARS) (особливо при використанні транзакцій), і такий підхід звучить так, що це призведе до того, що це трапляється частіше.

Я завжди дзвонив AsEnumerableабо ToArrayв кінці кожного з моїх виразів LINQ, щоб переконатися, що база даних потрапила, перш ніж залишати код сховища.

Мені цікаво, чи повернення IQueryableможе бути корисним як будівельний блок для рівня даних. Я бачив якийсь досить екстравагантний код з одного сховища, що викликає інше сховище, щоб створити ще більше IQueryable.

Повернення IQueryable, безумовно, надасть більшу гнучкість споживачам сховища. Це покладає на клієнта відповідальність за звуження результатів, що, природно, може принести користь і суть.

З іншого боку, вам не потрібно буде створювати тонни методів сховища (принаймні на цьому шарі) - GetAllActiveItems, GetAllNonActiveItems тощо - для отримання потрібних даних. Залежно від ваших уподобань, знову ж таки, це може бути добре чи погано. Вам потрібно (/ слід) визначити поведінкові контракти, яких дотримуються ваші реалізації, але де саме це залежить від вас.

Таким чином, ви можете розмістити логіку вишуканого пошуку поза сховищем і дозволити її використовувати, як хоче користувач. Таким чином, опромінення IQueryable дає найбільшу гнучкість і дозволяє ефективно запитувати, на відміну від фільтрації в пам'яті тощо, і може зменшити потребу в створенні тонни конкретних методів отримання даних.

З іншого боку, тепер ви дали своїм користувачам рушницю. Вони можуть робити те, чого ви, можливо, не планували (зловживайте .include (), роблячи великі важкі запити та здійснюючи фільтрацію в пам’яті у відповідних реалізаціях тощо), що в основному може поступово діяти на етапі управління шарами та поведінкою, оскільки ви надали повний доступ.

Тож залежно від команди, їх досвіду, розміру програми, загального шару та архітектури ... це залежить: - \

Розкривати IQueryable публічним інтерфейсам - це не дуже добра практика. Причина принципова: ви не можете забезпечити реалізацію IQueryable, як це прийнято.

Публічний інтерфейс - це договір між постачальником та клієнтами. І в більшості випадків очікується повна реалізація. IQueryable - це чіт:

1. IQueryable практично неможливо реалізувати. І наразі належного рішення немає. Навіть у Entity Framework є безліч непідтримуваних винятків .
2. Сьогодні провайдери Queryable мають велику залежність від інфраструктури. Sharepoint має свою часткову реалізацію, і мій постачальник SQL має чітку часткову реалізацію.

Шаблон сховищ дає нам чітке уявлення про шари та, головне, незалежність реалізації. Тож ми можемо змінитись у майбутньому джерелі даних.

Питання " Чи повинна бути можливість заміни джерела даних? ".

Якщо завтра частина даних може бути переміщена до служб SAP, бази даних NoSQL або просто до текстових файлів, чи можемо ми гарантувати належну реалізацію інтерфейсу IQueryable?

( більше хороших моментів щодо того, чому це погана практика)

Реально, у вас є три варіанти, якщо ви хочете відкласти виконання:

• Зробіть це так - викрийте IQueryable.
• Реалізуйте структуру, яка розкриває конкретні методи для конкретних фільтрів або "питань". ( GetCustomersInAlaskaWithChildren, нижче)
• Реалізуйте структуру, яка відкриває сильно набраний API фільтра / сортування / сторінки та створює IQueryableвнутрішньо.

Я віддаю перевагу третьому (хоч я і допоміг колегам впровадити другий), але, очевидно, є деякі налаштування та обслуговування. (Т4 на допомогу!)

Редагувати : Щоб усунути плутанину навколо того, про що я говорю, розгляньте наступний приклад, викрадений у IQueryable: може вбити вашу собаку, викрасти дружину, вбити свою волю до життя тощо.

У сценарії, де ви могли б викрити щось подібне:

public class CustomerRepo : IRepo 
{ 
     private DataContext ct; 
     public Customer GetCustomerById(int id) { ... } 
     public Customer[] GetCustomersInAlaskaWithChildren() { ... } 
} 

API, про який я говорю, дозволив би ви відкрити метод, який дозволив би ви GetCustomersInAlaskaWithChildrenгнучко виражати (або будь-яку іншу комбінацію критеріїв), а репо буде виконувати його як IQueryable і повертати вам результати. Але найважливіше те, що він працює всередині шару сховища, тому він все ще використовує переваги відкладеного виконання. Як тільки ви отримаєте результати, ви все ще можете LINQ-об’єкти на ньому, щоб вміст вашого серця.

Ще одна перевага такого підходу полягає в тому, що, оскільки вони є класами POCO, це сховище може жити за веб-службою або службою WCF; він може піддаватися впливу AJAX або інших абонентів, які не знають, що перше про LINQ.

Насправді існує лише одна обґрунтована відповідь: це залежить від того, яким чином потрібно використовувати сховище.

З одного боку, ваш сховище - це дуже тонка обгортка навколо DBContext, щоб ви могли ввести вінір доказів навколо програми, керованої базою даних. Насправді немає справжнього світового сподівання, що це може бути використане відключеним способом, не підтримуючи LINQ дружнього БД, оскільки ваш додаток CRUD ніколи цього не знадобиться. Тоді впевнено, чому б не використовувати IQueryable? Я, мабуть, вважаю за краще IEnumarable, оскільки ви отримуєте більшість переваг [читайте: затримка виконання], і це не так брудно.

Якщо ви не сидите в цій крайності, я б дуже намагався скористатися духом шаблону сховища і повернути відповідні матеріалізовані колекції, які не мають наслідку базового з'єднання з базою даних.

 > Should Repositories return IQueryable?

НІ, якщо ви хочете зробити testdriven development / unittesting, оскільки не існує простого способу створити макетний сховище для тестування вашого businesslogic (= репозиторія-споживача) у відриві від бази даних чи іншого постачальника послуг IQueryable.

З точки зору чистої архітектури, IQueryable - це проникна абстракція. В цілому він надає користувачеві занадто велику потужність. Як сказано, є місця, де це має сенс. Якщо ви використовуєте OData, IQueryable дозволяє надзвичайно легко надати кінцеву точку, яка легко фільтрується, відсортовується, групується ... тощо. Я фактично вважаю за краще створити DTO, на які мої сутності відображаються, а IQueryable повертає DTO замість цього. Таким чином я попередньо фільтрую свої дані і використовую лише метод IQueryable, щоб дозволити клієнтам налаштувати результати.

Я також зіткнувся з таким вибором.

Отже, підведемо підсумки позитивних та негативних сторін:

Позитивів:

• Гнучкість. Це, безумовно, гнучко і зручно, щоб дозволити клієнтові створювати власні запити лише одним методом сховища

Мінуси:

• Непереборний . (ви будете фактично тестувати основну реалізацію IQueryable, яка зазвичай є вашою ORM. Але замість цього ви повинні перевірити свою логіку)
• Розмиває відповідальність . Неможливо сказати, що робить конкретний метод вашого сховища. Насправді це бого-метод, який може повернути все, що вам подобається, у всій вашій базі даних
• Небезпечно . Без обмежень щодо того, що може бути запитано цим методом репозиторію, в деяких випадках такі реалізації можуть бути небезпечними з точки зору безпеки.
• Проблеми з кешуванням (або, загалом, будь-які проблеми перед або після обробки). Наприклад, нерозумно, наприклад, кешувати все у вашій програмі. Ви спробуєте кешувати щось, що спричинить значне навантаження вашої бази даних. Але як це зробити, якщо у вас є лише один метод репозиторію, який клієнти використовують, щоб видати практично будь-який запит до бази даних?
• Проблеми з журналом . Якщо щось записати на шарі сховища, ви змусите спочатку перевірити IQueryable, щоб перевірити, чи буде цей конкретний виклик введений чи ні.

Я б рекомендував не використовувати цей підхід. Розглянемо замість цього створити кілька Специфікацій та реалізувати методи репозиторію, які можуть запитувати базу даних, використовуючи ці. Специфікація є прекрасним способом інкапсуляції набору умов.

Я вважаю, що виставлення IQueryable у вашому сховищі цілком прийнятно на початкових етапах розробки. Є інструменти інтерфейсу користувача, які можуть безпосередньо працювати з IQueryable та обробляти сортування, фільтрування, групування тощо.

Якщо говорити, я вважаю, що просто виставляти сироту на сховищі і називати це щодня - це безвідповідально. Наявність корисних операцій та помічників для поширених запитів дозволяє централізувати логіку запиту, одночасно піддаючи меншу поверхню інтерфейсу споживачам сховища.

Перші кілька ітерацій проекту, викриття IQueryable публічно у сховищі дозволяє швидше зростати. Перед першим повним випуском я рекомендую зробити операцію запиту приватною або захищеною та привести дикі запити під один дах.

Що я бачив (і що я реалізую сам), це наступне:

public interface IEntity<TKey>
{
    TKey Id { get; set; }
}

public interface IRepository<TEntity, in TKey> where TEntity : IEntity<TKey>
{
    void Create(TEntity entity);
    TEntity Get(TKey key);
    IEnumerable<TEntity> GetAll();
    IEnumerable<TEntity> GetAll(Expression<Func<TEntity, bool>> expression);
    void Update(TEntity entity);
    void Delete(TKey id);
}

Це дозволяє вам зробити гнучкість робити IQueryable.Where(a => a.SomeFilter)запит на ваш репо, виконуючи concreteRepo.GetAll(a => a.SomeFilter)без викриття жодного бізнесу LINQy.