Stratificare un servizio WCF nel modo giusto

Question

La mia domanda è più di natura architettonica, meno coinvolta nella realizzazione effettiva.

Ho creato un'API basata su WCF, ma non riesco davvero a decidere come separare il PL dal BL. Ho snellito il mio servizio, in modo da contenere solo un minimo di implementazione, qualcosa come:

public TagItemResponse TagItem(TagItemRequest request)
{
   return (new ItemTagRequestProcessor()).GetResponse(request);
}

Che ovviamente sorge la prima domanda, a quale livello appartengono i RequestProcessor? Penso che sarebbe sbagliato chiamarli facciata, ma allo stesso tempo non hanno nulla a che fare con la presentazione. Per ora, ho deciso che comunque appartengono al PL. I metodi del processore prendono i miei DTO (DataContracts) come input, convalidano il messaggio di richiesta (classe base), eseguono l'autenticazione (classe base) e infine restituiscono una singola risposta DTO, in questo modo:

protected override void Process(TagItemRequest request, TagItemResponse response, Host host)
{
    var profile = ProfileFacade.GetProfile(host, request.Profile);
    var item = ItemFacade.GetItemId(host, request.Item);
    var tags = new List<Tag>();

    foreach (var name in request.Tags)
    {
        var tag = TagFacade.GetTag(profile, name);
        ItemFacade.TagItem(item, tag);
        tags.Add(tag);
    }

    ItemFacade.UntagItem(item, tags);
}

Ora mi chiedo, perché ho bisogno delle classi di facciata 1: 1 relative ai miei oggetti business. Ad esempio ho un HostFacade che funge da strato tra hostDAO e i processori. Tuttavia, contiene pochissima logica, gestisce semplicemente le chiamate DAO.

public static Host GetHost(HostDTO dto)
{
   return HostDAO.GetHostByCredentials(dto.Username, dto.Password);
}

Domanda: potrei anche unire i processori e le facciate, giusto?

Ho letto molti articoli / libri sull'argomento, ma non riesco ancora ad accontentarmi della strada "giusta" e tendo a scegliere un approccio diverso ogni volta che mi trovo ad affrontare il problema. Mi chiedo se esista un giusto approccio.

Ho trovato f.ex. l'esempio doFactory, in cui hanno parlato con le classi DAO direttamente dall'implementazione del servizio. Non mi piace molto, poiché la maggior parte dei metodi di ServiceContract condividono un po 'di logica e quindi si prestano bene per l'uso con classi di base condivise.

Ho anche trovato altri esempi in cui solo le facciate vengono chiamate all'interno dei servizi, ma sembra funzionare bene solo per messaggi molto precisi. I miei messaggi sono "fat" e compositi al fine di ridurre il più possibile il numero di chiamate al servizio. Il mio livello di elaborazione extra sembra essere il mio vero problema.

Probabilmente non c'è una sola risposta su come stratificare correttamente un servizio WCF, ma speriamo che ci siano alcuni di voi là fuori con un'opinione che o conformerà i miei istinti o getta una nuova luce sull'argomento per me.

Grazie!

Geoffrey

Answer 1

In primo luogo, presumo che per PL intendi livello di presentazione, non livello di persistenza?

Quando si implementa un progetto di applicazione a più livelli, la domanda principale dovrebbe essere sempre: posso sostituire l'implementazione di un livello inferiore senza influire sull'implementazione dei livelli sopra.

Questo è solitamente meglio illustrato dal livello di persistenza. Se si passa da SQL Server 2008 a MySQL, ad esempio, il livello di persistenza cambia (ovviamente). Ma sono necessari anche cambiamenti nel livello aziendale? Ad esempio, il livello aziendale rileva istanze SqlException che vengono generate solo da SqlClient? In un buon design, il livello aziendale non ha bisogno di modifiche.

Lo stesso principio dovrebbe applicarsi alla separazione tra livello aziendale e livello di presentazione.

Nel tuo esempio, direi che ItemTagRequestProcessor non dovrebbe essere nel livello di presentazione. In primo luogo, non ha nulla a che fare con la presentazione, in secondo luogo, l'implementazione dell'elaborazione di una richiesta non è un problema per il livello di presentazione. Confrontalo con un'applicazione Web, presentare un TagItemResponse a un client è la preoccupazione del livello Web (presentazione). Il recupero di un'istanza di <=> è una preoccupazione di un livello al di sotto del livello di presentazione.

Decidere se avere una facciata tra il livello aziendale e il livello di persistenza è difficile. Di solito non implemento una facciata perché aggiunge un ulteriore livello (solitamente non necessario) di indiretta. Inoltre, non vedo alcun problema nel chiamare i metodi del livello di persistenza direttamente dai metodi del livello aziendale. Se solo si tiene conto dello stesso principio: è possibile modificare l'implementazione del livello di persistenza senza influire sull'implementazione del livello aziendale.

Cordiali saluti,

Ronald Wildenberg