Czy separacja poleceń / zapytań dotyczy metody, która tworzy obiekt i zwraca jego identyfikator?

Udawajmy, że mamy usługę wywołującą proces biznesowy. Ten proces wywoła warstwę danych, aby utworzyć obiekt typu A w bazie danych.

Następnie musimy ponownie wywołać inną klasę warstwy danych, aby utworzyć instancję typu B w bazie danych. Potrzebujemy przekazać informacje o A dla klucza obcego.

W pierwszej metodzie tworzymy obiekt (modyfikujemy stan) i zwracamy jego identyfikator (zapytanie) w jednej metodzie.

W drugiej metodzie mamy dwie metody, jedną (createA) dla składowania i drugą (getId) dla zapytania.

    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);
    }

Z mojego zrozumienia, druga metoda w pełni uwzględnia separację zapytań poleceń. Uważam jednak, że marnotrawienie i sprzeczność z intuicją polega na przeszukiwaniu bazy danych w celu uzyskania właśnie utworzonego obiektu.

Jak pogodzić CQS z takim scenariuszem?

Czy tylko druga metoda jest zgodna z CQS, a jeśli tak, czy w takim przypadku lepiej ją zastosować?

CQS jest raczej wytyczną niż bezwzględną regułą. Zobacz artykuł wiki, aby zapoznać się z przykładami działań, które są niemożliwe przy ścisłym CQS.

Jednak w tym przypadku, jeśli chcesz zachować CQS, możesz albo utworzyć identyfikator po stronie klienta (np. GUID), albo klient może zażądać identyfikatora z systemu przed utworzeniem jakichkolwiek obiektów, co wydaje się czystsze mnie niż tworzenie obiektu, a następnie wyszukiwanie go (ale jest trudniejsze niż użycie kolumny tożsamości).

Osobiście po prostu zwrócę identyfikator i nazwałbym go jedną z tych sytuacji, w których CQS nie pasuje.

Kolejny dobry artykuł z przykładami: Martin Fowler

Jeśli zastosujesz metodologię, która wydaje się poprowadzić cię na złe ścieżki, powinieneś ją ponownie ocenić.

Widzę, że identyfikator nowo utworzonego obiektu jest prawidłową rzeczą, którą należy mieć jako parametr zwracany - jest nie tylko wygodny, ale także „dobry” - ponieważ widać, że kod jest lepszy, gdy to robi.

W każdym razie nie jestem zaznajomiony z „separacją zapytań poleceń”, ale bardzo wątpię, aby uniemożliwiało komendom zwracanie informacji o wykonywaniu poleceń, a jeśli tak, to po prostu wyrzuć je - sukces / porażka zawsze tam jest, i robię to nie myśl, że „Twój obiekt został utworzony OK” z „Twój obiekt został utworzony OK, a jego identyfikator to xxx”, aby być znacznie innym.

Tylko druga metoda jest zgodna z CQS.

Uważam CQS za wskazówkę zachęcającą do dobrych praktyk kodowania. Skorzystaj z dobrych praktyk kodowania podczas programowania, a jeśli później dowiesz się, że ta metoda zawiera kod krytyczny dla zasobów, nadal możesz go zoptymalizować.

Przedwczesna optymalizacja jest źródłem wszelkiego zła :)