EntityFramework это уже сторонняя вещь, правильно? И если клиентский код вызывает его методы, то у вас изначально бизнес логика завязана со сторонним фреймворком?
Насчёт CQRS не совсем понял, у вас агрегата не будет тогда? Если нет, то и без CQRS на отдельных репозиториях можно жить )
Если имеете ввиду, что кроме репозитория, другие механизмы будут уметь восстанавливать сущности из БД, то у вас размазываются знания об одной сущности на несколько механизмов.
По поводу разных БД, можно упростить - "у вас есть две разных БД", это более реальная ситуация.
Ещё раз упомяну, статья о паттерне, не о "серебреной пуле" в любой ситуации ?
Не соглашусь что про БД ни слова. В книге, Мартин многократно упоминает про базы данных(говоря о UoW). Сама глава про UoW начинается со слов - "Извлекая данные из базы данных ..."
В моём примере используются именно они, поэтому я и упоминаю, что UoW знает о них.
Если вы используете другие подходы, хорошо. Это не отменяет того что UoW должен знать о них и предоставлять клиентскому коду. Спасибо за обратную связь :)
От вашего UoW зависит UseCase. UseCase будет использовать конкретные зависимости из UoW. Если вы не раскрываете, что лежит в UoW, как UseCase(у) взаимодействовать с ним?
В стандартном исполнении это репозитории, так как UoW по канонам используется для баз данных. Если у вас используются другие паттерны для CRUD работы с БД, то расскажите пожалуйста ваш сценарий использования UoW.
Агрегат из другой архитектуры(ddd), мешать две архитектуры просто потому что, не мой подход.
тут я 10 раз подумаю, прежде чем создавать агрегат. Особенно из этих двух сущностей.
Создание агрегата должно быть обоснованно, и нужно понимать, какую ответственность это налагает.
С агрегатом вы обязаны управлять жизненным циклом обоих сущностей только через агрегат.
У вас не может быть репозитория клиент+менеджер, и отдельный только на менеджеров. Это сразу нарушит dry, так как ваши знания об одинаковых данных расползутся. Так же будет неправильным доступов к данным, так как с сущностями агрегата можно взаимодействовать только через агрегат.
Неудобства начинаются с самого начала, как только вам нужно получить менеджеров по какому то критерию, касающегося менеджеров.
Для этого вам нужно восстановить всех клиентов у кого будут эти менеджеры, и перебирая клиентов искать их.
Так же для сценария банального "получить всех менеджеров", мне нужно восстановить всех клиентов, взять из них всех менеджеров, и следить за уникальностью, потому что менеджеры могут повторяться.
Ну и заканчивая желанием просто перейти на карточку менеджера, нужно восстановить из памяти весь агрегат, прежде чем получить о нём информацию.
Это ещё всё не так страшно. Если ваш агрегат содержит несколько сущностей, или подчинённая сущность имеет множество вхождений, то при восстановлении агрегата у вас будут восстанавливаться тысячи или десятки тысяч объектов, когда вам нужен лишь один.
Не говоря уже о двух разных сущностных, когда их не объединить в агрегат при всём желании.
Если, как вы говорите, повесить транзакционность уровнем выше чем юзкейс, то ваш юзкейс будет неполноценным.
Во первых, сам юзкейс теряет возможность выделять эту самую логическую транзакцию.
Во вторых, юзкейс как единица вашей бизнес логики на самом деле не обеспечивает её корректность, потому что нужен кто то сверху, кто будет следить за атомарностью.
В третьих, там где вы хотите повесить транзакцию, предположу что это контроллер, вы будете фреймворком зависит от выбора бд.
И так будет работать, но нужно понимать, что это нарушение, и идти на него с осознанием этого, а не просто делать как легче.
Подскажите, что мне сделать если один репозиторий mysql, другой postgresql, третий вообще не sql. Кто должен уметь держать три разные транзакции? Контроллер? Сомневаюсь :)
В завершении повторюсь, что эта статья имеет ознакомительный характер. Не я придумал этот паттерн, и не призываю бездумно использовать его.
Квадратные скобки используются также при: list[0], str[::], dict["key"].
Круглые скобки используются ещё для генерации генераторов (x for x on y), выделения условий и мат. операций (2 + 2) * 2, средством переноса кода без применения "/", вызов любого callable объекта происходит через ().
Фигурные скобки используются в f-string f"{argument}".
Спасибо за обратную связь! В статье я не пытался раскрыть, что такое "литерал". Я хотел рассказать, как работают генераторы коллекций. Коллекция в программирование это объект, который содержит в себе другие объекты, и предоставляет открытый интерфейс для доступа к этим данных.
EntityFramework это уже сторонняя вещь, правильно? И если клиентский код вызывает его методы, то у вас изначально бизнес логика завязана со сторонним фреймворком?
Не буду вас переубеждать ?
Если это возможно, покажите минимальный пример, как вы взаимодействуете с UoW в клиентском коде :)
Насчёт CQRS не совсем понял, у вас агрегата не будет тогда? Если нет, то и без CQRS на отдельных репозиториях можно жить )
Если имеете ввиду, что кроме репозитория, другие механизмы будут уметь восстанавливать сущности из БД, то у вас размазываются знания об одной сущности на несколько механизмов.
По поводу разных БД, можно упростить - "у вас есть две разных БД", это более реальная ситуация.
Ещё раз упомяну, статья о паттерне, не о "серебреной пуле" в любой ситуации ?
Не соглашусь что про БД ни слова. В книге, Мартин многократно упоминает про базы данных(говоря о UoW). Сама глава про UoW начинается со слов - "Извлекая данные из базы данных ..."
В моём примере используются именно они, поэтому я и упоминаю, что UoW знает о них.
Если вы используете другие подходы, хорошо. Это не отменяет того что UoW должен знать о них и предоставлять клиентскому коду. Спасибо за обратную связь :)
От вашего UoW зависит UseCase. UseCase будет использовать конкретные зависимости из UoW. Если вы не раскрываете, что лежит в UoW, как UseCase(у) взаимодействовать с ним?
В стандартном исполнении это репозитории, так как UoW по канонам используется для баз данных. Если у вас используются другие паттерны для CRUD работы с БД, то расскажите пожалуйста ваш сценарий использования UoW.
Спасибо за обратную связь!
Агрегат из другой архитектуры(ddd), мешать две архитектуры просто потому что, не мой подход.
тут я 10 раз подумаю, прежде чем создавать агрегат. Особенно из этих двух сущностей.
Создание агрегата должно быть обоснованно, и нужно понимать, какую ответственность это налагает.
С агрегатом вы обязаны управлять жизненным циклом обоих сущностей только через агрегат.
У вас не может быть репозитория клиент+менеджер, и отдельный только на менеджеров. Это сразу нарушит dry, так как ваши знания об одинаковых данных расползутся. Так же будет неправильным доступов к данным, так как с сущностями агрегата можно взаимодействовать только через агрегат.
Неудобства начинаются с самого начала, как только вам нужно получить менеджеров по какому то критерию, касающегося менеджеров.
Для этого вам нужно восстановить всех клиентов у кого будут эти менеджеры, и перебирая клиентов искать их.
Так же для сценария банального "получить всех менеджеров", мне нужно восстановить всех клиентов, взять из них всех менеджеров, и следить за уникальностью, потому что менеджеры могут повторяться.
Ну и заканчивая желанием просто перейти на карточку менеджера, нужно восстановить из памяти весь агрегат, прежде чем получить о нём информацию.
Это ещё всё не так страшно. Если ваш агрегат содержит несколько сущностей, или подчинённая сущность имеет множество вхождений, то при восстановлении агрегата у вас будут восстанавливаться тысячи или десятки тысяч объектов, когда вам нужен лишь один.
Не говоря уже о двух разных сущностных, когда их не объединить в агрегат при всём желании.
Если, как вы говорите, повесить транзакционность уровнем выше чем юзкейс, то ваш юзкейс будет неполноценным.
Во первых, сам юзкейс теряет возможность выделять эту самую логическую транзакцию.
Во вторых, юзкейс как единица вашей бизнес логики на самом деле не обеспечивает её корректность, потому что нужен кто то сверху, кто будет следить за атомарностью.
В третьих, там где вы хотите повесить транзакцию, предположу что это контроллер, вы будете фреймворком зависит от выбора бд.
И так будет работать, но нужно понимать, что это нарушение, и идти на него с осознанием этого, а не просто делать как легче.
Подскажите, что мне сделать если один репозиторий mysql, другой postgresql, третий вообще не sql. Кто должен уметь держать три разные транзакции? Контроллер? Сомневаюсь :)
В завершении повторюсь, что эта статья имеет ознакомительный характер. Не я придумал этот паттерн, и не призываю бездумно использовать его.
Спасибо за вашу обратную связь.
Согласен, я не обратил внимание, что оставил там абстракцию, такого высокого уровня.
Считаю что может быть абстрактная UoW, но отыгрывать через композицию в конкретных реализациях UoW или фабриках которые собирают это UoW.
Иначе просто наш бизнес код будет зависеть от деталей реализации.
Не совсем понял о каком интерфейсе вы говорите.
Так же не утверждаю, что UoW единственный/лучший вариант. Всё зависит от ситуации.
И статья имеет ознакомительный характер.
Уверен, что кто-то найдёт ему достойное применение )
Ещё раз спасибо!
Эти коллекции не хешируемые, так как являются изменяемыми типами данных.
Множество и словарь это разные типы данных, с разными интерфейсами взаимодействия. Множество не имеет порядка и доступа по ключу.
Также операции и задачи в которых используются эти типы данных, отличаются.
Квадратные скобки используются также при: list[0], str[::], dict["key"].
Круглые скобки используются ещё для генерации генераторов (x for x on y), выделения условий и мат. операций (2 + 2) * 2, средством переноса кода без применения "/", вызов любого callable объекта происходит через ().
Фигурные скобки используются в f-string f"{argument}".
Итог - на всех не хватит разных видов скобок :)
Спасибо за обратную связь! В статье я не пытался раскрыть, что такое "литерал". Я хотел рассказать, как работают генераторы коллекций. Коллекция в программирование это объект, который содержит в себе другие объекты, и предоставляет открытый интерфейс для доступа к этим данных.
Здравствуйте. У меня сложные примеры?