Чи застосовується розділення команд / запитів до методу, який створює об'єкт і повертає його ідентифікатор?

Зробимо вигляд, що у нас є сервіс, який викликає бізнес-процес. Цей процес зажадає рівень даних для створення об’єкта типу А в базі даних.

Після цього нам потрібно знову зателефонувати на інший клас рівня даних, щоб створити екземпляр типу B у базі даних. Нам потрібно передати деяку інформацію про A для зовнішнього ключа.

У першому методі ми створюємо об'єкт (змінюємо стан) і повертаємо його ідентифікатор (запит) в один метод.

У другому методі у нас є два методи: один (createA) для збереження та інший (getId) для запиту.

    public void FirstMethod(Info info)
    {
        var id = firstRepository.createA(info);           
        secondRepository.createB(id);
    }

    public void SecondMethod(Info info)
    {
        firstRepository.createA(info);
        var key = firstRepository.getID(info);
        secondRepository.createB(key);
    }

З мого розуміння, другий метод більш повно випливає з розділення запитів команд. Але я вважаю марним і неінтуїтивним запитувати базу даних, щоб отримати об'єкт, який ми тільки що створили.

Як ви погоджуєте CQS з таким сценарієм?

Чи відповідає лише другий метод CQS, і якщо так, то бажано використовувати його в цьому випадку?

CQS - це керівництво, а не абсолютне правило. Дивіться статтю у wiki для прикладів заходів, які неможливі в умовах суворого CQS.

Однак у цьому випадку, якщо ви хочете підтримувати CQS, ви можете або створити ідентифікатор на стороні клієнта (наприклад, GUID), або клієнт може запросити ідентифікатор від системи перед створенням будь-яких об'єктів, які відчувають себе чистішими мені, ніж створювати об’єкт, то запитувати його (але важче, ніж просто використовувати стовпчик ідентичності).

Особисто я просто повертаю ідентифікатор і називаю це однією з тих ситуацій, коли CQS не підходить.

Ще одна гарна стаття з прикладами: Мартін Фаулер

Якщо ви дотримуєтесь методології, і вона, здається, сприймає вас погані шляхи, вам слід переоцінити її.

Я бачу, що ідентифікатор новоствореного об'єкта є дійсною річчю, яка має бути як параметр повернення - це не просто зручно, але це також "добре" - як ви бачите, код краще, коли він робить.

У будь-якому випадку я не знайомий з "розділенням запитів команд", але я дуже сумніваюся, що він забороняє командам повертати інформацію про виконання команди, і якщо це так, просто сміття - успіх / провал завжди є, і я не думайте, що "ваш об'єкт був створений ОК" з "ваш об'єкт був створений ОК, і його ідентифікатор - ххх", щоб набагато відрізнятися.

Тільки другий метод слідує за CQS.

Я вважаю, що CQS є орієнтиром для заохочення належних методів кодування. Використовуйте хороші практики кодування під час розробки, і якщо пізніше з’ясуєте, що цей метод містить критично важливий ресурс, ви все одно можете його оптимізувати.

Передчасна оптимізація - корінь усього зла :)