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

S>Возьмем типичную реализацию метода веб сервиса. Предположим у нас метод работает с какими-то там доменными сущностями типа Пользователь.

Т.е. задача редактирования справочника, вписывается в обозначенные мной сценарии. Вопрос, это приложение только создаёт/редактирует Пользователя или обладает ещё какой-то функциональностью?

S>UnitOfWork это во первых транзакция, я всегда могу ее отролбечить,

И в чём проблема? Транзакции — это святое, это наше всё. Зачем для этого UoW?

S>всегда могу из контекста достать данные без обращения в базу. Репозитории содержат в себе логику по доступу к данным. Иногда специфичную для данного ОРМ. Типа QueryOver, желательно Linq (но не всегда это возможно), иногда даже Dapper. Но такие случаи нужно избегать и до последней возможности стараться писать на linq.

Я без всяких UoW работаю только на Linq. Включая временные таблицы, хинты, bulk copy и прочее. Иногда приходится дописывать свои хелперы типа на отключение констрейнов, но это мелочи и разовая работа.

S>Репозитории могут понадобится в других сервисах. Например, получение пользователей для данной организации на данном этаже происходит не только при оповещении о создании нового пользователя, но и при пожарной тревоги.

Техники повторного использования кода вообще-то никто не отменял. Это всё можно сделать массой разных способов. Да и сам репозиторий как паттерн вполне можно использовать без UoW.

S>Отправка сообщений — много где нужна, во многих сервисах. И даже создание пользователя может происходить неявно также во многих случаях.

Техники повторного использования кода. UoW здесь вовсе не панацея.

S>Таким образом мы имеем четкую структуру. Каждый из классов имеет свою обязанность. Смена ОРМ происходит максимально легко. Конечно это не просто подмена файлика — методы репозиториев и быть может даже сервисов нужно будет переписывать.

И сколько раз в своей жизни ты менял ОРМ в своих проектах? Только честно.

S>Теперь вопрос. Что с этой схемой не так? Как выглядит работа с linq2db? Скорее всего это файл сервиса на 2000 строк где все вперемешку.

Это зависит от задачи. Бывает, что 2000 строк это не предел. Бизнес логика — она такая бизнес логика. Если нужно написать кода на 2000 строк, то здесь не поможет никакой UoW.

S>P.S. Здесь говорили что менять ОРМ часто не надо. Забавно, но изначальный пост был как раз про это. ОРМ вам нужно поменять, например, при переходе на Core. И вы хотите минимизировать правки.

linq2db позволяет менять не только Core, но даже БД без изменения кода бизнес логики. Это вообще как бы не вопрос. И, кстати, Core — это не ОРМ, это фреймворк.

В общем, я в очередной раз не понял зачем нужен UoW.

Есть ещё один философский момент. Все эти UoW, Entity Services, Persistence и прочее, всё это от лукавого. Если хочется работать с базой данных эффективно и надёжно, без гемороя и сайд эффектов, то с базой данных нужно работать именно как с базой данных. Любые попытки поставить между базой и кодом магический щит в виде UoW и прочей дребедени заканчивается очень быстро и наступает жестокое разочарование.