17-77ссылки я почитал и в связи с этим задал вопрос, если у вас не было такой ситуации, это не значит что их вообще не существует, а история следующая: проект, прототип, первая версия, MS SQL Compact 3.5 + LINQ-to-SQL, внезапно появляется элементарное требование - сделать пейджинг на страницах, чтобы не 1000 записей, а по 10,20,...

SQL Compact 3.5 не умеет этого в нативном sql, сменили версию на 4.0, только вот LINQ-to-SQL не умеет с ней, пришлось менять ORM, на EF, было около 20-30 выделенных репозитеориев (интерфейс + реализация для LINQ + реализация для MOCK), сколько было мест использований - не считал, на все ушло полдня-день, плюс еще сделали дженерик для пейджинг-коллекций со свойствами TotalCount / PageCount / PageSize

Сочувствую. Вы выбрали убогую технологию. С ней невозможно построить сколь-нибудь приличное приложение. Вот и занялись заменой того-сего. Пробовали выйти за пределы microsof echo chamber? Там много всего интересного! Честно-честно.

Насчёт IQueryable - его по-настоящему поддерживает только linq-to-object. Все остальные провайдеры лишь небольшую его часть, причем все по разному. Работая с ним вы используете дырявую абстракцию, т.к. ориентируетесь на конкретный механизм доступа к данным. Подробнее .

Для сложных приложений всегда приходится ориентироваться на конкретный тип доступа к данным из соображений эффективности. Поэтому хороший построить репозиторий, который действительно легко заменить можно только ценой потери эффективности (гибкое управление ленивой загрузкой, количеством запросов к бд, количеством загружаемых записей и т.д.). Это плата не для меня.

besserebrenikМне, честно говоря нравится более второй подход, как было отмечено 17-77, он гибче
Каждая абстракция отрезает низкоуровневые возможности, вы сознательно их игнорируете. Иногда это хорошо, иногда не очень. С данными это всегда не очень. Представьте себе, что есть интерфейс:


Если этот интерфейс имеет реализует холодильник - проблем нет. Захотели пообедать - сходили к холодильнику. А теперь представьте себе, что в арктической экспедиции, и IFoodRepository реализует корабль, который приплывает к вам раз в полгода. Сможете ли вы игнорировать этот факт?

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

ViPRos,

если что - то меня не впечатляет.

ViPRosпочему?
Алексей КПотому что проще воспользоваться тем же WPF + нормальный бизнес-фреймворк, чем вводить метаданные + править ядро ВипРоса в случае нетиповых ситуаций.

Отвечу сразу обоим. Дело даже не в WPF как таковом, дело глобальнее. Программистов (и тех кто рядом) уже давно волнуют некоторые больные вопросы софтостроения, удачное решения для которых бередит умы опытных и неопытных программистов. Одну из них - доступ к данным - мы сейчас активно мусолим. Но единого победоносного варианта нет. Всегда приходится искать способы сгладить углы на мультиугольнике. Серебряных пуль не подвезли.

Еще одна особо голубая мечта человечества - писать программы без программистов. Уже не одно поколение средств померло в попытках родить нечто, что может выкинуть дорогих программистов из процесса создания ПО. Всякие case-средства, нонче вот народ любит с BPL баловаться. Но у этих попыток есть две большие проблемы:
1. Создание средства, которое позволяло бы моделировать что-либо на достойном уровне очень-очень невероятно сложно само по себе, и требует миллионы человеко-лет труда. Далеко не всем конторам это под силу. Но даже решение этой проблемы бессмысленно, из-за второй проблемы.
2. Программирование сложно само по себе. Малое количество пользователей может формализовать проблему. А уж запрограммировать (пусть мышкой) - это высший пилотаж. Приходится нанимать консультантов, чтобы они могли настроить систему . Это уже не говоря про другие вопросы: как управлять конфигурацией, как класть изменения в контроль версий и управлять изменениями, как проводить аудит, как тестировать, как отлаживать, как решать вопросы производительности и т.д. и т.п. Даже более простая задача - конфигурация приложения - это тоже программирование, и требует для своего обслуживания высококвалифицированный персонал. Всё это сводит на нет все теоретические плюсы мышкопрограммируемых систем. С их помощью можно родить только очень простой CRUD-софт.
Это эдакий вечный двигатель в разрезе программирования.

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