Utilizzo dell'API Fluent [chiuso]

Question

Utilizzo dell'API Fluent [chiuso]

#1 da (4 voti)
#2 da (2 voti)

1

So che possono essere più naturali da scrivere, ma trovo concettualmente difficile "leggere" le catene di metodi API fluide. C'è così tanto da fare in un paio di righe.

Come esempio dell'API Nest ElasticSearch:

 var result = Client.Search<AutoSuggestItem>(s => s
    .Source(sf => sf
        .Includes(f => f
            .Field(ff => ff.Actual)
            .Field(ff => ff.Text)
            .Field(ff => ff.TextSearch)
        )
    )
    .Suggest(su => su
        .Completion("suggestions", c => c
            .Prefix(SearchText)
            .Field(p => p.Suggest)
        )
    )

);

Qualche consiglio su questo, oltre al debugging?

c# visual-studio

posta Matthew Evans 21.09.2017 - 14:39

fonte

2 risposte

2

Diverso dal rientro del codice in un modo che faciliti l'analisi per te (come tenere una chiamata per riga), temo che non ci sia molto altro da fare.

Per quanto riguarda il debug, se si tratta di una libreria di terze parti, non vedo davvero il problema, perché sarà una scatola nera per te. Con il corretto rientro, il debugger evidenzierà una riga alla volta (con l'ovvia eccezione di lambdas lunghi in cose come Select() di LINQ).

Se è una libreria che tu ha scritto, ricorda cosa ha detto Brian Kernighan:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Se il tuo codice è semplice, passare da un'API fluente non è affatto diverso dal debug di qualsiasi vecchio metodo (che in molti casi è una vera e propria API interamente fatta di).

Io amo una API fluentemente progettata, così tanto che probabilmente dovrei cercare la sintassi della query di LINQ, poiché preferisco di gran lunga il metodo uno.

Ci sono cose specifiche con cui stai avendo problemi?

risposta data 21.09.2017 - 15:10

fonte

Leggi altre domande sui tag c# visual-studio

Decidere sulla corretta progettazione dell'URL RESTful Sovraccarico dell'utilizzo di singleton grandi con tutti i file inclusi

score 4 · Accepted Answer

Ho usato API buone e cattive fluenti. Trovo che semplici API che ti aiutano a assemblare la configurazione in blocchi logici sono molto utili. Tuttavia, le API in cui sono presenti callback lambda e così via sono molto difficili da seguire a causa del contesto nidificato.

La mia risposta all'addominio di un'API scorretta è di fare quanto segue:

Indentazione (questo è un minimo indispensabile)
Prepara lambdas al di fuori del contesto della chiamata più grande, oppure se il bit è condiviso tra diversi metodi, crea un metodo per riempire gli spazi vuoti.

Questo mi permette almeno di capire i pezzi usati nella richiesta più grande, e poi quando sono incorporati posso capire come si relazionano tra loro.

Un esempio in cui un implementatore di API ha ascoltato i propri utenti: al credito del team ElasticSearch, hanno riconosciuto che la loro API NEST Fluent a volte impediva di creare query in modo dinamico. Hanno anche fornito un modo per assemblare le query senza l'API fluente. Questo è il meglio di entrambi i mondi. Puoi usare l'API fluente quando ha senso ed evitarlo quando necessario.