Entity Framework или почему я реализую Repository

5) Написать билдер

это делается 1 раз,

Кто помешает там написать плохой запрос?

ни кто, но это будет не в 10 местах по коду, а в одном, и так же легко поправиться

Entity Framework или почему я реализую Repository

Я работаю над проектом, в котором два боевых слоя хранилища и еще одно демонстрационное.

Прогноз на Specification pattern в Domain layer — ожидаются проблемы

А что делать, если после того, как клиент выбрал место (и оно заблокировано), клиент отвалился?

удалит запись о блокировке из таблицы.

Но это никак не отменяет существования этой проблемы.

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

Прогноз на Specification pattern в Domain layer — ожидаются проблемы

та, что касается паралельной работы, я думаю все таки идеальный вариант — это симбиоз клиента и бд.

Прогноз на Specification pattern в Domain layer — ожидаются проблемы

приходит клиент, выбирает место, кассир блокирует место, поле оплаты подтверждается продажа, билет продан блокировка снята.

lock escalation

а где я про это писал?

Entity Framework или почему я реализую Repository

ну и опять мы вернулись IQuariable, вы же сами указывали

If you have a specific ORM in mind, then be explicit about it. Don't hide it behind an interface. It creates the illusion that you can replace one implementation with another. In practice, that's impossible.

Entity Framework или почему я реализую Repository

Тот же самый, но меньше возможностей у клиента покрошить выполнение, тк он ограничен запросом синтаксически.

Entity Framework или почему я реализую Repository

Build(filtrate,query.Paging) надо будет скопипастить как минимум в половине билдеров.

тоже самое что и рассматривать за копипаст Skip(n).Take(k), для особого извращения это все можно сделать с помощью рефлексии ( крайне не рекомендую ) универсально.

А твой подход рождает изрядное количество копипасты.

запросы изменяются для каждого репозитория отдельно, причем эти запросы специфический, такие запросф как Paging с точки зрения предметной области меняться не будут, может меняться только их построение.

А кто помешает программисту написать любой запрос внутри репозитария?

ни кто, но так он будет находиться в конкретном месте.

кроме компилятора рассчитывать не на что.

к сожалению компилятор не в силах распознать LINQ запросы которые приведут к краху, тк с точки зрения статического анализа они верны, но перевести их в SQL imposible.

Прогноз на Specification pattern в Domain layer — ожидаются проблемы

ответ описал ниже

Прогноз на Specification pattern в Domain layer — ожидаются проблемы

Каждый билет имеет уникальный номер ( признак ), на уровне бд делаем уникальность по полю, и в таблицу блокировок одни и те же билеты (места) не попадут ( хотя это можно расценивать как паранойю

Параноики еще и в самом хранилище делают проверки.

)

Прогноз на Specification pattern в Domain layer — ожидаются проблемы

Таблица блокировок, туда помещается записи о местах которые покупают на данный момент.

Прогноз на Specification pattern в Domain layer — ожидаются проблемы

Один клиент редактирует документ, пока он это делает другой не может вносить изменения

Entity Framework или почему я реализую Repository

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

Entity Framework или почему я реализую Repository

Не у каждого query будет Paging.

вот именно! каждый из репозиториев будет принимать свой тип запроса.

случай работает сильно медленнее

а вы можите написать выражение которое будет делать скип и тэйк быстрее?

Тогда репозиторий превратится в бизнес-логику.

то есть если query является составным query.UserOptions и query.OrderOptions то обработка этого запроса это бизнес уровень, а написать LINQ запрос который будет получать пользователей по определенному критерию заказов — это нет. А в чем разница?

Думаешь у программистов, которые пишут репозитории другая совесть?

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

Entity Framework или почему я реализую Repository

и вы будите анализировать epression tree и на его осннове формировать новый AST (как вы любите писать)?

Entity Framework или почему я реализую Repository

GetFooByParamSet2(paramSet2);
GetFooByParamSet3(paramSet3);
//--------
GetFooByParamSetN(paramSetN);

а что, не плохо. мы только что ограничили запросы, а вот теперь нам нужно получить элементы по paramSet2 и paramSet3, и вот

GetFooByParamSetN+1(paramSetN+1);

100% рабочий вариант, спору нет, но чем он лучше? проще — да, но попытка комбинирования запросов приводит к разрастанию интерфейса — это нормально?

Entity Framework или почему я реализую Repository

расшифруйте.

Entity Framework или почему я реализую Repository

ни кем, синтаксически можна написать сколь угодно сложные выражения, которые не возможно перевести в sql, и об этом узнается только при исполнении.

Прогноз на Specification pattern в Domain layer — ожидаются проблемы

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

Прогноз на Specification pattern в Domain layer — ожидаются проблемы

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