Korzystanie z zasad SOA zamiast OOD w kodzie nienależącym do usługi

Question

Nasz architekt mówił o użyciu technik SOA w całym naszym kodzie źródłowym, nawet w interfejsach, które w rzeczywistości nie są hostowane jako usługa. Jedną z jego próśb jest to, że projektujemy nasze metody interfejsu, abyśmy nie mieli żadnych założeń co do faktycznej implementacji. Jeśli więc mamy metodę, która przyjmuje obiekt i wymaga aktualizacji właściwości tego obiektu, musimy wyraźnie zwrócić obiekt z tej metody. W przeciwnym wypadku polegalibyśmy na tym, że coś jest typem referencyjnym, a C# pozwala nam domyślnie aktualizować właściwości na typie referencyjnym.

Więc:

public void SaveSomething(Something something) 
{ 
    //save to database 

    something.SomethingID = 42; 
} 

staje:

public Something SaveSomething(Something something) 
{ 
    //save to database 

    return new Something 
    { 
    //all properties here including new primary key from db 
    }; 
} 

nie mogę uzyskać moja głowa wokół korzyści z takiego podejścia i zastanawiałem się, czy ktoś mógłby pomóc?

Czy to jest wspólne podejście?

Answer 1

Myślę, że twój architekt stara się, aby twój kod miał mniej efektów ubocznych. W twoim konkretnym przykładzie nie ma korzyści. W wielu przypadkach twój architekt będzie miał rację, a będziesz mógł zaprojektować duże części aplikacji bez skutków ubocznych, ale jedno miejsce, w którym nie może się to zdarzyć, jest podczas operacji przeciwko bazie danych.

Co trzeba zrobić, to zapoznać się z funkcjonalnym programowaniem i przygotować się do rozmów o takich przypadkach z architektem. Pamiętaj, że jego intencje są najprawdopodobniej dobre, ale konkretne przypadki są twoją domeną. W tym przypadku efektem ubocznym jest , a najprawdopodobniej chcesz zwrócić typ boola, aby wskazać powodzenie, ale zwracanie nowego typu nie ma sensu.

Pokaż architektowi, że rozumiesz ograniczające skutki uboczne, ale pewne efekty uboczne muszą być dozwolone (baza danych, interfejs użytkownika, dostęp do sieci itd.), A prawdopodobnie się okaże, że on/ona zgadza się z tobą. Znajdź sposób na wyodrębnienie pożądanych efektów ubocznych i wyjaśnij jemu, a to pomoże w twojej sprawie. Twój architekt prawdopodobnie doceni to, jeśli zrobisz to w duchu współpracy (nie próbując robić dziury w swoim planie).

Parę środki na FP:

1. A great tutorial on Functional Programming
2. Wikipedia's entry on Functional programming

Powodzenia, mam nadzieję, że to pomaga.