Re[7]: IQueryable + DataContext
От: Sinix  
Дата: 26.10.15 10:40
Оценка:
Здравствуйте, __SPIRIT__, Вы писали:

__S>Но вот почему народ считает что нельзя вернуть кверибл из репозитория и как в таком случае избежать адского колличества специализированных методов(типа проставь флаг всем ордерам за последний месяц) абсолютно не понятно.


Потому что EF заточен под сайты/сервисы, а не под работу с UI.
Из коробки нет ни явной operation scope, ни локальных транзакций => или получаем весьма разнообразные баги, или извращаемся с "как использовать iqueryable, ничего не захватив".
Re[8]: IQueryable + DataContext
От: __SPIRIT__ Россия  
Дата: 26.10.15 12:38
Оценка:
Здравствуйте, Sinix, Вы писали:

__S>>Но вот почему народ считает что нельзя вернуть кверибл из репозитория и как в таком случае избежать адского колличества специализированных методов(типа проставь флаг всем ордерам за последний месяц) абсолютно не понятно.


S>Потому что EF заточен под сайты/сервисы, а не под работу с UI.


т.е. речь только про десктопные приложения? А на сервере все ок?

S>Из коробки нет ни явной operation scope, ни локальных транзакций => или получаем весьма разнообразные баги, или извращаемся с "как использовать iqueryable, ничего не захватив".


в десктопе, не нужно так делать 100%.
Re[9]: IQueryable + DataContext
От: Sinix  
Дата: 26.10.15 13:47
Оценка: +2
Здравствуйте, __SPIRIT__, Вы писали:

__S>т.е. речь только про десктопные приложения? А на сервере все ок?

А на сервере в моде stateless-сервисы. Т.е. держать контекст на всё время вызова как бы не страшно — всё равно вызовы стараются сделать как можно более короткими.
Как всегда, есть частные случаи, но по умолчанию подход работает.

S>>Из коробки нет ни явной operation scope, ни локальных транзакций => или получаем весьма разнообразные баги, или извращаемся с "как использовать iqueryable, ничего не захватив".

__S>в десктопе, не нужно так делать 100%.

Ну так нет стандартного подхода для UI, вот в чём печаль. Кто-то от отчаяния лепит всё ручками, ч/з mvvm, кто-то переизобретает датасеты, кто-то пытается сделать полноценный фреймворк с биндингом, сериализуемым self change tracking с передачей client<>server и вложенными транзакциями и тыды и тыпы.

На практике я пока не видел ни одного варианта, который по удобству хотя бы не уступал вечному легаси — датасетам. Особенный юмор ситуации в том, что сами датасеты на вершину дизайна тоже не тянут, от слова совсем
Re[7]: IQueryable + DataContext
От: Vladek Россия Github
Дата: 26.10.15 14:50
Оценка:
Здравствуйте, __SPIRIT__, Вы писали:

__S>Очевидно что самый быстрый вариант ответа на вопрос "в чем проблема вернуть кверибл?" это дать ссылку без лишних слов и идей на полуторачасовое видео...


В чем проблема просто использовать DbContext там, где требуется "репозиторий"? Что вообще из себя представляет этот репозиторий? Я догадываюсь, что это просто супер-тонкая обёртка контекста — ну и какой в ней смысл?

Смысла в ней мало, начиная с названия — это не репозиторий, это шлюз таблицы, если судить по названиям методов типичного "репозитория". (table data gateway). Но даже как шлюз таблицы он не соответствует описанию — мы не контролируем формирование запросов к бд, которые используются приложением (они окончательно формируются за пределами этого класса); соответственно, мы не контролируем весь доступ к бд в одном месте. Сначала оно работает, потом оно начинает медленно работать, потом однажды перестаёт работать. С чего вдруг? Не знаю, дебажить надо — в этом коде без дебага уже не разберёшься. Потом меняются требования, мы правим метод у нашего класса — слегка меняем запрос, но по-прежнему возвращаем IQueryable. Где-то что-то ломается. Мы дебажим и чиним.

Или нет, не так — мы никогда не трогаем этот класс, это ведь тот же самый DbContext. Запросы меняются в других местах, по всему приложению. Чего плохого в Entity Framework? Ничего, отличная технология. Только настоящий репозиторий может её использовать, а может и не использовать — ему контракт позволяет это делать. Он управляет коллекцией объектов из предметной области — может, читает их из бд; может, из файловой системы или памяти — никто об этом, кроме него, не знает. Нельзя вот так просто взять и возвратить IQueryable из репозитория — потому что объекты предметной области не имеют ничего общего с объектами маппинга таблиц бд, они от них никак не зависят. Это чистые объекты (с полями и методами), сферические кони в вакууме, представляющие собой ядро приложения, бизнес-логику. Если приложение не моделирует предметную область (нормальная ситуация, есть другие подходы к решению задач), то и репозитории ему не нужны.

Я не вижу смысла скрывать DbContext под тонкой обёрткой — всё равно никто, кроме EF или другого полноценного LINQ-провайдера (NHibernate и вроде бы всё?), реализовать контракт IQueryable в полной мере не в состоянии. Это самообман (у нас есть репозитории!) и карго-культ (ну как же так, без репозиториев-то?).
http://files.rsdn.org/43395/hr-kyle-theisen-04.png
Re[9]: IQueryable + DataContext
От: Vladek Россия Github
Дата: 26.10.15 14:51
Оценка:
Здравствуйте, __SPIRIT__, Вы писали:

__S>в десктопе, не нужно так делать 100%.


Вот с этим
public interface IRepository
{
    IQueryable<T> Query<T>();
}

я могу делать что угодно и где угодно. А кто мне запретит?
http://files.rsdn.org/43395/hr-kyle-theisen-04.png
Re[4]: IQueryable + DataContext
От: TK Лес кывт.рф
Дата: 26.10.15 16:13
Оценка: +1
Здравствуйте, Doc, Вы писали:

Doc>Т.е. нет необходимости поддерживать живым контекст до окончания работы IQueryable?


Нет не обходимыми его создавать до того, как понадобились реальные данные. IQueryable это в первую очередь описание запроса. Поддержка в нем IEnumerable это попытка скрещивания ужа с ежом.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[8]: IQueryable + DataContext
От: __SPIRIT__ Россия  
Дата: 26.10.15 16:44
Оценка:
Здравствуйте, Vladek, Вы писали:

__S>>Очевидно что самый быстрый вариант ответа на вопрос "в чем проблема вернуть кверибл?" это дать ссылку без лишних слов и идей на полуторачасовое видео...


V>В чем проблема просто использовать DbContext там, где требуется "репозиторий"? Что вообще из себя представляет этот репозиторий? Я догадываюсь, что это просто супер-тонкая обёртка контекста — ну и какой в ней смысл?


1) что делать со сторед функциями если "репозитория" нет? Они получаются глобальными что не удобно.
2) легче мокать
3) можно подключать другие источники данных тем же способом IQueryable<...> и вперед. (Это предположение, нам пока это не нужно но на первый взгляд все должно работать на ура)

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

V>Смысла в ней мало, начиная с названия — это не репозиторий, это шлюз таблицы, если судить по названиям методов типичного "репозитория". (table data gateway). Но даже как шлюз таблицы он не соответствует описанию — мы не контролируем формирование запросов к бд, которые используются приложением (они окончательно формируются за пределами этого класса); соответственно, мы не контролируем весь доступ к бд в одном месте. Сначала оно работает, потом оно начинает медленно работать, потом однажды перестаёт работать. С чего вдруг? Не знаю, дебажить надо — в этом коде без дебага уже не разберёшься.


Во первых дебаг это не плохо, тут критерий один: Как быстро можно определить проблему. Если из дебага это можно сделать быстро — ок.

V>Потом меняются требования, мы правим метод у нашего класса — слегка меняем запрос, но по-прежнему возвращаем IQueryable.


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

V>Где-то что-то ломается. Мы дебажим и чиним.


и тесты либо эксепшен при первом обращении в базу нам говорят где и что.

V>Или нет, не так — мы никогда не трогаем этот класс, это ведь тот же самый DbContext. Запросы меняются в других местах, по всему приложению. Чего плохого в Entity Framework? Ничего, отличная технология. Только настоящий репозиторий может её использовать, а может и не использовать — ему контракт позволяет это делать. Он управляет коллекцией объектов из предметной области — может, читает их из бд; может, из файловой системы или памяти — никто об этом, кроме него, не знает. Нельзя вот так просто взять и возвратить IQueryable из репозитория — потому что объекты предметной области не имеют ничего общего с объектами маппинга таблиц бд, они от них никак не зависят. Это чистые объекты (с полями и методами), сферические кони в вакууме, представляющие собой ядро приложения, бизнес-логику. Если приложение не моделирует предметную область (нормальная ситуация, есть другие подходы к решению задач), то и репозитории ему не нужны.


Во первых нельзя все от всего изолировать. Колличество оверхеда будет такое что этот подход никогда не окупится и будет непрерывно увеличивать стоимость решения.
Очевидно что для любой такой системы можно найти небольшое изменение требований которое потребует полной либо масштабной переделки. Почему то его всегда находят...

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

Вот и нужно искать баланс. Вот например зачем ты пытаешься из репозитория вернуть не сырые объекты? Зачем ограничивать бизнес логику? Да дальше бизнеслогики пускать сырые данные опасно и зачастую неудобно...


V>Я не вижу смысла скрывать DbContext под тонкой обёрткой — всё равно никто, кроме EF или другого полноценного LINQ-провайдера (NHibernate и вроде бы всё?), реализовать контракт IQueryable в полной мере не в состоянии. Это самообман (у нас есть репозитории!) и карго-культ (ну как же так, без репозиториев-то?).


да назови его как хочешь
Re[10]: IQueryable + DataContext
От: __SPIRIT__ Россия  
Дата: 26.10.15 16:48
Оценка: :)
Здравствуйте, Vladek, Вы писали:

__S>>в десктопе, не нужно так делать 100%.


V>Вот с этим

V>
V>public interface IRepository
V>{
V>    IQueryable<T> Query<T>();
V>}
V>


Скорее так:
public interface IRepository<T>
{
    IQueryable<T> Query();
}


V>я могу делать что угодно и где угодно. А кто мне запретит?

В смысле в десктопе такой подход с кверибл не нужно применять вообще. Он впринципе нужен только для того чтобы работать с большими объемами данных, а на клиенте такого не бывает(за редким исключением).
Re[11]: IQueryable + DataContext
От: Sinix  
Дата: 26.10.15 17:55
Оценка:
Здравствуйте, __SPIRIT__, Вы писали:

__S>В смысле в десктопе такой подход с кверибл не нужно применять вообще. Он впринципе нужен только для того чтобы работать с большими объемами данных, а на клиенте такого не бывает(за редким исключением).


Любой энтерпрайз-софт (особенно всякие erp). Настраиваемые пользователем представления по любому из словарей — стандартное требование, olap-кубы в реалтайме — уже признак хорошего тона. Словарей (упрощённо, таблиц с данными) — сотни, если не тысячи, количество записей — от миллиона и пока скромность не треснет.

Конечно, можно переизобрести свой аналог IQueryable<T> (на самом деле в большинстве систем так и сделано, потому что писались задолго до), но суть будет та же — ast запроса на входе, грид/куб на выходе.
Re[12]: IQueryable + DataContext
От: __SPIRIT__ Россия  
Дата: 26.10.15 18:31
Оценка:
Здравствуйте, Sinix, Вы писали:

__S>>В смысле в десктопе такой подход с кверибл не нужно применять вообще. Он впринципе нужен только для того чтобы работать с большими объемами данных, а на клиенте такого не бывает(за редким исключением).


S>Любой энтерпрайз-софт (особенно всякие erp). Настраиваемые пользователем представления по любому из словарей — стандартное требование, olap-кубы в реалтайме — уже признак хорошего тона. Словарей (упрощённо, таблиц с данными) — сотни, если не тысячи, количество записей — от миллиона и пока скромность не треснет.


S>Конечно, можно переизобрести свой аналог IQueryable<T> (на самом деле в большинстве систем так и сделано, потому что писались задолго до), но суть будет та же — ast запроса на входе, грид/куб на выходе.




Это что за софт если не секрет? Видимо мне клиенты не то что тонкие а вполне себе тощие попадаются. (Я правда >90% времени серваками занимаюсь)
Re[13]: IQueryable + DataContext
От: Sinix  
Дата: 26.10.15 19:40
Оценка:
Здравствуйте, __SPIRIT__, Вы писали:

__S>


__S>Это что за софт если не секрет? Видимо мне клиенты не то что тонкие а вполне себе тощие попадаются. (Я правда >90% времени серваками занимаюсь)

Внутренние/заказные. Там на самом деле ничего сложного, чтобы вытащить данные запросом из готового куба/привязать к чему-то типа такого много ума не надо. А звучит страшно, да

В массовых 1с/парус/галактике/ктотамещё, насколько знаю, вместо "кубов везде" в основном используются аналитические отчёты, изредка добавляют аналитику для самых популярных таблиц фактов. Насколько оно удобнее в виде отчётов — это к клиентам
Re[2]: IQueryable + DataContext
От: MozgC США http://nightcoder.livejournal.com
Дата: 26.10.15 20:35
Оценка:
Здравствуйте, Слава, Вы писали:

С>Отказаться от понятия "репозиторий" вообще. Как тут советуют создатели linq2db.


А где такое советовали? Создатель linq2db сам использует репозиторий в своем проекте на работе. Но этот репозиторий не возвращает IQueryable, он возвращает List<>. Т.е. например List<Customer> Customers. С помощью setter'а можно подменить этот список для тестов, а в getter'е обычно что-то типа (упрощенно):
get
{
  if(_customers == null)
  {
    using(var db = new DataModel())
    {
      _customers = db.Customers.ToList();
    }
    AfterCustomersLoaded();
  }
  return _customers;
}
http://www.brainbench.com/images/certlogo/color/mastercert/csharp50.gif
Re[14]: IQueryable + DataContext
От: __SPIRIT__ Россия  
Дата: 27.10.15 13:34
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, __SPIRIT__, Вы писали:


__S>>


__S>>Это что за софт если не секрет? Видимо мне клиенты не то что тонкие а вполне себе тощие попадаются. (Я правда >90% времени серваками занимаюсь)

S>Внутренние/заказные. Там на самом деле ничего сложного, чтобы вытащить данные запросом из готового куба/привязать к чему-то типа такого много ума не надо. А звучит страшно, да

S>В массовых 1с/парус/галактике/ктотамещё, насколько знаю, вместо "кубов везде" в основном используются аналитические отчёты, изредка добавляют аналитику для самых популярных таблиц фактов. Насколько оно удобнее в виде отчётов — это к клиентам


меня больше всего удивили анализ миллионов данных на клиенте. ИМХО очень расточительно и есть большие сомнения по юзабельности такого клиента.
Re[15]: IQueryable + DataContext
От: Sinix  
Дата: 27.10.15 13:50
Оценка:
Здравствуйте, __SPIRIT__, Вы писали:

__S>меня больше всего удивили анализ миллионов данных на клиенте. ИМХО очень расточительно и есть большие сомнения по юзабельности такого клиента.

А, ну значит я криво написал. На сервере всё, на клиента вытаскивать — маразм полнейший (как всегда, есть исключения, но мы не про них).
Re[14]: IQueryable + DataContext
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.10.15 15:15
Оценка: 36 (1)
Здравствуйте, Sinix, Вы писали:

S>В массовых 1с/парус/галактике/ктотамещё, насколько знаю, вместо "кубов везде" в основном используются аналитические отчёты, изредка добавляют аналитику для самых популярных таблиц фактов. Насколько оно удобнее в виде отчётов — это к клиентам

в 1С так называемые агрегаты http://v8.1c.ru/overview/Term_000000564.htm
и солнце б утром не вставало, когда бы не было меня
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.