не на много больше чем все эти критерии засунуть в LINQ
который не является неотъемлемой частью Repository и прекрасно реализуется на других уровнях).
как сказать.
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
действительно про запросы ни где не сказано, но использовать чистый Repository, как и любую абстракцию сложно, одно ясно что запрос должен идти в терминах предметной области и передаваться репозиторию, для этого можно использовать QueryObject или другой подход, но то что реп должен умет все это переводить в запросы хранилища и именно он должен это делать.
Наверное, вами же реализованы? Вот и увеличение ресурсных затрат.
хорошую архитектуру бесплатно не получить.
Ох. Давайте пойдем сначала. Вот есть проблема: не всякий запрос, переданный в DAL снаружи (и, как следствие, сформулированный в терминах объектов), можно преобразовать в запрос в терминах хранилища. Я правильно вас понял, или вы что-то другое имеете в виду?
все что можно написать в LINQ запросах не всегда можно отразить в SQL запросе.
Значит, репозиторий не отвечает на этот вопрос, он просто сдвигает его в предметную область. QED.
Передав запрос в терминах предметной области в репозиторий, который итерпритирует его и возвращает то, что требуется в запросе.
Расскажите это пользователю (настоящему реальному пользователю вашей программы), который хочет выбирать данные по заказчикам, отфильтрованные по произвольному критерию поверх 18 признаков.
а почему все эти 18 критериев не описать в объекте запроса?
«как сослаться на свойство „возраст“ класса „сотрудник“»?
конкретный репозиторий возвращает определенный тип объектов, запросы для получения этих объектов нужно формировать запросы, по которым реп разберет что от него хотят. Проблемы в упор не вижу.
Во-первых, вы передергиваете: нигде не сказано, что эта задача не имеет решения; сказано лишь что не всегда возможно сгенерировать корректный SQL для всех БД для любого AST. Но предположим на минуту, что вы правы, и эта задача действительно не имеет решения. Как же репозиторий ее решает в таком случае?
Задача не имеет решения. я это комментирую
написано причем не мной
Однако это не всегда возможно.
на
и эта задача действительно не имеет решения. Как же репозиторий ее решает в таком случае?
на это ответ выше, можно выполнить другой эквивалентный запрос внутри репозитория.
как представлять произвольный фильтр в Query Object?
произвольный фильтр это зло, мы должны ограничить пользователя, тк сразу появяться дубли запросов по коду, почему это плохо, надеюсь писать не придется.
как ссылаться на свойства объектов в Query Object?
расшифруйте, я не понял
как отображать пейджинг и сортировку в Query Object?
И как же репозиторий позволяет обойти эти проблемы? Вероятно, вы имеете в виду, что вы напишете две разных реализации репозитория для двух разных провайдеров. Это здорово, но вы помните, что вы только что увеличили свои затраты вдвое?
В двое? Я реализую абстракцию, которая позволит переопределить обработку запросов отдельно, и в каждой реализации переопределю только не эффективные.
и вообще на поддержание полудесятка введенных абстрактных слоев, практический смысл которых ускользает.
есть несколько вопросов, на которые отвечают эти абстракции
1. Что делать если нужно поменять слой данных, а нужного провайдера нет или он тугой ( вряд ли можно утверждать, что смена провайдера окажется без болезнена )
2. Каким образом предоставлять запросы для получения данных? (на прямую через linq?)
3. Как сохранять сущности? (процесс сохранения мб сложнее чем просто добавить объект в контекст)
…
Repository отвечает на все эти вопросы.
Интерпретируемые языки программирования отличаются тем, что исходники не преобразовываются в машинный код для непосредственного выполнения на ЦПУ, а исполняются с помощью специальной программы-интерпретатора.
Как промежуточный вариант, многие языки (Java, C#, Python) транслируются в машинно-независимый байт-код,
который все еще не может быть исполнен напрямую на ЦПУ, и чтобы его исполнить все еще необходим интерпретатор.
Почему интерпретация медленней? Ответ на этот вопрос, как ни странно не всем кажется очевидным, хотя он действительно очень простой: интерпретируя каждую команду по отдельности, мы затрачиваем дополнительные ресурсы на перевод семантики этой команды на язык процессора. Кроме того современные процессоры оптимизированы для выполнения последовательных команд (см. Конвейер), а интерпретатор чаще всего представляет собой огромный switch с кучей опций, загоняющий в тупик предсказатель переходов.
EF так же является обёрткой, которая так же замедляет выполнение. .NET использует интерпретатор для исполнения программ, что так же замедляет, причем сильно. Вообще если нужна максимальная скорость, то скорее всего нужно работать на прямую с хранилищем (например с sql) и уже «чистые» данные мапить в домен ( тут хорошо подходит Repository ). При таком подходе со слоями будет меньше всего проблем, без потери производительности. Но есть 1 ОГРОМНЫЙ -минус — это надо делать самому.
При нашем подходе замена хранилища не составит труда, но его менять не зачем. Домен действительно не простой, и у нас большой минус — отсутствие документации, поэтому нам важны чистые описания объектов предметной области (интерфейсы). Оптимизация это проблема, с которой приходиться бороться. Но я сторонник «Код лучшая документация».
Я считаю что предметная область не должна зависеть от области хранения. Яблоко будет оставаться яблоком и не важно где оно будет лежать холодильник, стол, сумка.
Я имею ввиду что объекты предметной области могут сильно отличаться от того какими объектами они хранятся. Пример на ходу в бд одна таблица с кучей полей, в домене эта свалка представлена 2 объектами по средствам агрегации.
не на много больше чем все эти критерии засунуть в LINQ
как сказать. действительно про запросы ни где не сказано, но использовать чистый Repository, как и любую абстракцию сложно, одно ясно что запрос должен идти в терминах предметной области и передаваться репозиторию, для этого можно использовать QueryObject или другой подход, но то что реп должен умет все это переводить в запросы хранилища и именно он должен это делать.
хорошую архитектуру бесплатно не получить.
все что можно написать в LINQ запросах не всегда можно отразить в SQL запросе.
а почему все эти 18 критериев не описать в объекте запроса?
конкретный репозиторий возвращает определенный тип объектов, запросы для получения этих объектов нужно формировать запросы, по которым реп разберет что от него хотят. Проблемы в упор не вижу.
в базовом репозитории.
Задача не имеет решения. я это комментирую
на
на это ответ выше, можно выполнить другой эквивалентный запрос внутри репозитория.
зависит только от предметной области
произвольный фильтр это зло, мы должны ограничить пользователя, тк сразу появяться дубли запросов по коду, почему это плохо, надеюсь писать не придется.
расшифруйте, я не понял
так же как и суть запроса
В двое? Я реализую абстракцию, которая позволит переопределить обработку запросов отдельно, и в каждой реализации переопределю только не эффективные.
написано причем не мной
на это я ответил выше.
что касательно есть несколько вопросов, на которые отвечают эти абстракции
1. Что делать если нужно поменять слой данных, а нужного провайдера нет или он тугой ( вряд ли можно утверждать, что смена провайдера окажется без болезнена )
2. Каким образом предоставлять запросы для получения данных? (на прямую через linq?)
3. Как сохранять сущности? (процесс сохранения мб сложнее чем просто добавить объект в контекст)
…
Repository отвечает на все эти вопросы.
взял от сюда habrahabr.ru/company/spbau/blog/250841
вопрос на сколько? однозначно сказать не могу, но факт.
Конечно надо, но это не самое страшное, больше всего времени затрачивает маппинг.
Вообще не понял, но каждую абстракцию кто то должен реализовывать и ух как здорово если ее кто то нормально реализовал за тебя.