Fungus,

упрощенно
сервис - это метод который дергается по сети
бизнес логика - вызывается сервисом , что то делает полезное и часто но не всегда (один метод бизнес логики всегда другой никогда третий как повезет) использует ORM/DbContext .

Сервис перед тем как вызвать бизнес логику создает транзакцию и/или "Entity framework DbContext"

как сервис создает и передает транзакцию в бизнес логику - как хочет хоть параметрами хоть IOC interceptor.

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

FungusVar79,
Примерно это я и предлагаю. В моем понимании есть репозитории, и сервисы дергающие их и реализующую бизнес логику (без жесткого запрета вызовов друг друга). Я как раз ищу слой, который бы занимался транзакциями.
В вашем варианте сервисы это некий дополнительный слой, который и оперирует транзакцией. А "бизнес логика" в вашей реализации, это, то что я называю сервисами. Только мне не ясно в каком виде эта бизнес логика предстает. Что она из себя представляет и в чем ее отличие от сервисов ?


сервисы это слой над бизнес логикой, до ужоса примитивный, нужен как обертка для создания всяких транзакций, UoW и всяких прочих инжектирований.
сервисы не дергают репозиттории, репозитории это DAL, сервисы дергают только логику, логика чото делает и дергает либо другую логику либо дал DAL, если захочет.
сервисы дергают только логику, метод сервиса содержит только грубо говоря одну строку - вызов метода логики ну или еще создания объектов для параметров метода логики например объект транзакции.
сервисы точка входа для инжектирования. логика - для алгоритмов. dal/repositories - для внешней среды файликов бдшек (может даже для сети?)

автор(один метод бизнес логики - всегда вызывает dal, другой - никогда, третий - как повезет)

FungusskyANA,

Если приложение разбито на разные DLL, у которых свои сущности. То у этих DLL должны же быть свои собственные DbContext ? Не один же общий иметь, с куче DbSet'ов. В этом случае не ясно как оперировать несколькими DbContext в рамках UOW - в рамках одной транзакции.EF такое вообще позволяет?
Пример. У нас есть DLL которая оперирует пользователями системы, и DLL оперирующая документами системами. Предположим есть процесс "Создать пользователя и документ, соответствующий этому событию". Не ясно как сделать это в рамках предложенного кода. Я и топик то создал в поисках такого решения.
засуньте в UoW список тех DbContext-ов которые в данном вызове сервиса использует метод бизнес логики, измините код UoW что бы он пробежался по этому списку и у всех DbContext-ов сделал SaveChanges, если один SaveChanges упал откатываем транзакцию например
возможно IOC нужно настроить что бы он смотрел какие DbContext нужны бизнес логики и фигачил в этот лист DbContext

FungusСервисы и призваны вызывать слой DAL.
что за ерунда. везде пишут что контролеры/ сервисы должны быть тонкими, то что сервис можно сделать толстым не значит что это нужно делать

FungusСервисы и призваны вызывать слой DAL. еще раз, для альтернативно одаренных, три слоя сервисы - бизнес логика - DAL

Где тут сервисы вызывают DAL?

Fungus,

чукча не читатель чукча задаватель вопросов

FungusVar79,

Контроллеры тонкими да. Но сервисы это и есть бизнес логика в моем понимании. И она может выйти весьма жирной: создание сущностей через репы, обращение к другим сервисам. Возможно мы говорим об одном и том же, просто терминология разная. Что у вас понимается под бизнес логикой. Это какие то классы, как выглядят ?
бизнес логика -
такс пришли бананы на 100 000 USD
и арбузы на 20 000 EUR
лезем в другую логику за курсом usd и eur
получаем тугрики
ага но ведь тугрики это не надежно, пересчитаем в банки тушенки для этого вызовем третью логику
получили вагон тушенки
дал запиши к нам пришло вагон тушенки

FungusНо сервисы это и есть бизнес логика в моем понимании. ну так херач всё в сервисах зачем тебе DAL IOC и всякая непонятная фигня, понапридумывают же, сиди мучайся

FungusСмузиЯ считаю, что транзакция - вещь атомарная, переводящая данные из одного целостного состояния в другое целостное состояние. Выводить атомарность в сторонние методы и слои - архитектурная ошибка. Вроде как очевидные вещи. Во-вторых, грубая ошибка иметь несколько экземпляров EF контекстов в сервисах? Думаю, комментировать не требуется.

Ну так как реализовать то, что я описал в "Примере" тут 19926472 ? Иметь один контекст, в котором будут все все все сущности ? И юзеры, и их роли, и документы бизнес слоя и логирование в придачу.
грубая ошибка иметь несколько экземпляров EF контекстов в сервисах - не знаю как на счет в сервисах, но можно иметь много разнотипных контекстов главное что бы в одной транзакции.

FungusИметь один контекст, в котором будут все все все сущности ? И юзеры, и их роли, и документы бизнес слоя и логирование в придачу.

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

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