Confronto di specificazione del modello, Func predicati e Pipes & Filtri

Question

Sto facendo un lavoro di ricerca e sviluppo, e come tale sto esplorando modelli di progettazione. Sono stato di recente leggendo sul modello di specifica ed è stato denominato questo grande articolo.

Sono rimasto affascinato dalla semplicità e pulizia del codice, ma ho iniziato a disegnare alcuni confronti di attuare la stessa pulizia con altre tecniche.

Si consideri il seguente contratto di interfaccia per un livello di servizio:

public interface IFooDataService
{
   ICollection<Foo> GetFoosBySpecification(Specification<Foo> specification);
   ICollection<Foo> GetFooByPredicate(Func<Foo,bool> predicate);
   ICollection<Foo> GetFooBySearchArgs(FooSearchArgs searchArgs);
}

Quindi, alcuni punti iniziali:

• Tutti e tre di ritorno una collezione di oggetti Foo
• Tutti e tre prendono un solo argomento
• Specification metodo limita l'accesso alle specifiche esigenze
• metodo predicato ha fondamentalmente alcuna restrizione
• Cerca args metodo limita l'accesso alle specifiche esigenze

Ora, sulla implementazione:

public ICollection<Foo> GetFoosBySpecification(Specification<Foo> specification)
{
    return fooDataRepository
            .Find()
            .Where(f => specification.IsSatisfiedBy(f))
            .ToList();
}

public ICollection<Foo> GetFooByPredicate(Func<Foo, bool> predicate)
{
    return fooDataRepository
            .Find()
            .Where(predicate)
            .ToList();
}

public ICollection<Foo> GetFooBySearchArgs(FooSearchArgs searchArgs)
{
    return fooDataRepository
            .Find()
            .WhereMeetsSearchCriteria(searchArgs)
            .ToList();
}

Punti sull'attuazione:

• Tutti e tre sono estremamente semplice nella realizzazione (una riga di codice incatenato)
• Specification e ricerca Args filtrato eseguite esternamente.
• Ricerca args metodo utilizza semplicemente metodo di estensione IEnumerable per ispezionare args

Quindi, detto questo, in quali condizioni usereste uno dei sopra 3 tecniche?

Il mio pensiero su specifica del modello:

• Nizza in quanto isola i requisiti di business / dominio in componenti riutilizzabili
• Estremamente facile da leggere, rende il codice parlare inglese
• bel po 'di codice coinvolti (interfacce, classi astratte). Se dovessi usare questo, vorrei mettere le astrazioni in un comune di montaggio (così io non ho un gruppo di file statici nella mia soluzione).
• Facile da esigenze di cambiamento, cambiando solo le specifiche, e non livello di servizio.
• Suprema verificabilità della logica di dominio (specifiche)

I miei pensieri sui metodi di estensione (Pipe e filtri):

• 'Weighty' in logica, ma ancora comportare la stessa semplicità.
• logica di query isolare dallo strato servizio a metodi statici
• richiede ancora "riflesso" di sorta (controllo in dotazione args ricerca e la costruzione di query)
• Consente di architettura di codice (repository, livello di servizio) prima, senza pensare a specifici requisiti aziendali (che è utile in alcuni scenari)

Il mio pensiero su Metodo Predicate:

• Può essere utilizzato in cui è necessario a grana grossa controllo sulle query.
• Per piccoli progetti, in cui specifiche possono essere strafare

La mia logica pensiero finale è che se si sta lavorando su un'applicazione aziendale complessa in cui i requisiti di business sono noti in anticipo, ma possono cambiare nel corso del tempo, quindi vorrei usare Specifica modello.

Ma per un'applicazione che è un "avvio", vale a dire i requisiti evolveranno nel tempo e ha una moltitudine di modi per recuperare i dati senza convalida complesso, vorrei utilizzare i Tubi e metodi Filtri.

Quali sono i tuoi pensieri? Qualcuno di voi incorrere in problemi con uno qualsiasi dei metodi di cui sopra? Tutti i consigli?

per iniziare un nuovo progetto in modo da questi tipi di considerazioni sono fondamentali.

Grazie per l'aiuto.

Modifica chiarimenti su specifiche modello

Ecco stesso uso del pattern specifica.

Specification<Foo> someSpec; // Specification is an abstract class, implementing ISpecification<TEntity> members (And, Or, Not, IsSatisfiedBy).
someSpec = new AllFoosMustHaveABarSpecification(); // Simple class which inherits from Specification<Foo> class, overriding abstract method "IsSatisfiedBy" - which provides the actual business logic.    
ICollection<Foo> foos = fooDataService.GetFoosBySpecification(someSpec);

Answer 1

Dalla mia piccola esperienza:

1. esigenze degli utenti sempre cambiare e io non so perché il mio capo permette sempre che i cambiamenti a venire. Così uno alla specifica
2. programmatore qui è più come "manovale" che "knowledge worker". Sai .. quello che tipi tutto il giorno. Utilizzando specifica, posso garantire me stesso che "tipi" la tua vacanza. Questo è supportato dalla natura del mio progetto. Ha bisogno di molti molti implementazione diverso per lo stesso scopo. Non chiedetemi perché.
3. Usa un modello di progettazione che ti dà massima modularità e flessibilità e, naturalmente, testabilità. Ecco una piccola storia.
   In un bel giorno, il mio compagno mi ha detto che ha scritto una classe che ci ha permesso di calcolare 32 tipi di modo di calcolare X. E ha già implementato tutto ciò. Hoho, che era una programmazione tale eroica credo. Ha trascorso diverse settimane fa che nel bel mezzo della notte. Credeva che fosse un buon programmatore così ha insistito a tutti di usare il suo capolavoro.
   Noi, in quel momento, non si cura di test di unità così abbiamo usato il suo capolavoro. E poi che è successo? Il codice è caduto tutto il tempo. Beh, da quel momento ho capito quanto sia importante prova di unità e modularità sono.

Answer 2

Bene, prima che avrei scritto il metodo predicato, anche se è utilizzato solo come dettaglio di implementazione privata per gli altri due:

private ICollection<Foo> GetFoosBySpecification(Specification<Foo> spec) 
{ 
    return GetFooByPredicate(f => spec.IsSatisfiedBy(f));
} 

La funzione di ricerca tesi sarebbe un simile one-liner.

Al di là di questo, non posso davvero dire nulla in astratto. Avrei dovuto conoscere meglio la struttura dei dati per decidere il modo migliore per cercare di loro.