Я ни разу не противоречил. Можешь посмотреть типичную реализацию UoW и репозитория и сравнить их с контекстом. Мало найдешь сходств)
Чтобы ты не гуглил поясню.
Репозиторий
В контексте ты указываешь параметры подключения к бд, сущности бд и много чего еще(начальные данные, действия после сохранения и.т.п). При обращении к сущности из контекста у тебя есть доступ к crud операциям ИМЕННО этой сущности. Если у тебя 10 сущностей, то у тебя будет 10 репозиториев(чаще всего). А 100 сущностей? Все 100 репозиториев получать через di?
UoW
Типичная реализация - свойства-репозитории. Кусок
^3
Если приложить максимум усилий, то от UoW можно взять, что свойства-сущности - свойства-репозитории, а сама сущность внутри контекста - этакий репозиторий. Но все это сделано настолько гениально насколько другие яп не могут сделать. Zero говнокода.
Мб еще хранимые процедуры вызываешь, запивая все это антипаттернами? 
UPD:
Хотя какие ты проекты там делаешь, если не знаешь про мок, тесты и прочее? Далее консультация платная: 5000р/ч от будущего архитектора. 
Нажмите, чтобы раскрыть...
Я как раз таки знаю про мок, тесты и прочее, попросил тебя скинул пример того что ты описал, но ты слился, и проигнорил другие вопросы
И у тебя снова проблемы с терминологией, реализация и паттерн это разные вещи, зачем сравнивать с контекстом если это и есть реализация этих паттренов.
Если у тебя в бизнес функции используется 100 репозиториев то такого архитектора я бы и за бесплатно не стал брать, ибо это больше вопросы к проектированию, потому что ты явно смешиваешь кучу бизнес доменов в 1 и это очень нездоровая тема, ну а если тебе в TODO листах или что ты там делаешь не нужен RAW SQL или ты его не знаешь не думай что так все делают, я посмотрел бы как ты аналитические запросы сторишь в ORM и как они потом у тебя отрабатывают 
UPD:
А про UoW ты вообще какую то ахинею написал, ты хоть сам то понял?