Utilizzo di principi SOA su OOD in codice non-service

Question

Il nostro architetto ha parlato dell'utilizzo di tecniche SOA attraverso il nostro codebase, anche su interfacce che non sono effettivamente ospitate come servizio. Una delle sue richieste è che progettiamo i nostri metodi di interfaccia in modo da non fare ipotesi sull'attuale implementazione. Quindi, se abbiamo un metodo che accetta un oggetto e ha bisogno di aggiornare una proprietà su quell'oggetto, abbiamo esplicitamente bisogno di restituire l'oggetto dal metodo. Altrimenti ci faremo affidamento sul fatto che Something è un tipo di riferimento e C# ci consente di aggiornare le proprietà su un tipo di riferimento per impostazione predefinita.

Quindi:

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

    something.SomethingID = 42; 
} 

diventa:

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

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

non posso davvero ottenere la mia testa intorno i vantaggi di questo approccio e chiedevo se qualcuno potrebbe aiutare?

È un approccio comune?

Answer 1

Penso che il tuo architetto stia cercando di far sì che il tuo codice abbia meno effetti collaterali. Nel tuo esempio specifico, non c'è un vantaggio. In molti, molti casi, il tuo architetto avrebbe ragione, e puoi progettare ampie parti della tua applicazione senza effetti collaterali, ma un posto che questo non può accadere è durante operazioni contro un database.

Quello che dovete fare è prendere confidenza con la programmazione funzionale, e prepararsi per le conversazioni su casi come questi con il vostro architetto. Ricorda che le sue intenzioni sono probabilmente buone, ma casi specifici sono il tuo dominio. In questo caso, l'effetto collaterale è il punto e molto probabilmente si desidera che un tipo di ritorno di bool indichi il successo, ma restituire un nuovo tipo non ha senso.

Mostra al tuo architetto che comprendi la limitazione degli effetti collaterali, ma alcuni effetti collaterali devono essere consentiti (database, interfaccia utente, accesso alla rete, eccetera) e probabilmente troverai che è d'accordo con te. Trova un modo per isolare gli effetti collaterali desiderati e renderli chiari a lui o lei, e aiuterà il tuo caso. Il tuo architetto lo apprezzerà probabilmente se lo fai nello spirito di collaborazione (non cercando di fare buchi nel suo piano).

risorse

una coppia per FP:

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

Buona fortuna, spero che questo aiuta.