Questo codice di repository viola SRP e DRY?

0

Dopo aver letto questa domanda StackOverflow mi sono imbattuto in un articolo di MSDN Implementazione dei modelli di repository e unità di lavoro in un'applicazione MV.NET di ASP.NET .

Esiste una proposta di implementazione di un repository:

public virtual IEnumerable<TEntity> Get(
    Expression<Func<TEntity, bool>> filter = null,
    Func<IQueryable<TEntity>, IOrderedQueryable<TEntity>> orderBy = null,
    string includeProperties = "")
{
    IQueryable<TEntity> query = dbSet;

    if (filter != null)
    {
        query = query.Where(filter);
    }

    foreach (var includeProperty in includeProperties.Split
        (new char[] { ',' }, StringSplitOptions.RemoveEmptyEntries))
    {
        query = query.Include(includeProperty);
    }

    if (orderBy != null)
    {
        return orderBy(query).ToList();
    }
    else
    {
        return query.ToList();
    }
}

Recentemente ho incolpato le persone per il codice simile, dal momento che a mio parere quel codice era cattivo, e ora sono confuso.
I miei argomenti:

  • Chiunque utilizzi questo metodo deve conoscere ed elencare tutte le proprietà incluse di una classe
  • Ogni volta che qualcuno usa questo metodo in un nuovo codice, deve ricordare quali proprietà richieste deve includere, quindi probabilmente copierà e incollerà il caso d'uso precedente
  • Se qualcuno decide di cambiare il nome della proprietà, allora dovrebbe Ctrl + Maiusc + F attraverso un progetto e modificare tutti gli usi testuali
  • Se qualcuno aggiunge una proprietà che dovrebbe essere inclusa ovunque, allora dovrebbe trovare tutti gli usi e aggiungere ", Nuova proprietà" a ogni stringa

Per me sembra una violazione di SRP , DRY e altre regole di OOP.

Non posso credere che qualcuno come tdykstra possa scrivere codice cattivo, quindi dovrebbe esserci qualcosa che non riesco a capire e che mi fa sentirsi tristi. Potresti spiegare dove ho fatto un errore?

    
posta Yeldar Kurmangaliyev 31.05.2017 - 11:40
fonte

1 risposta

4

Ci sono davvero due problemi separati:

1) Tu vorrà decidere da caso a caso quali proprietà hai bisogno di caricare con impazienza in una query. Le proprietà di carico che non usate causano sovraccarico, e se avete caricato tutto con entusiasmo, la query caricherà l'intero database. D'altra parte, se hai bisogno delle proprietà allora il caricamento lento causerebbe il problema n + 1 che è anche un killer delle prestazioni.

2) Specificare le proprietà come stringhe. Questo ha davvero i problemi che hai citato. C'è un'alternativa strongmente tipizzata - vedi: link

Detto questo, il metodo sembra sovrascrivibile ai miei occhi. Sarebbe più semplice se esponesse IQueryable e permettesse al client di aggiungere filtri e ordinamenti in linq. Tagliare il filtraggio e ordinare in parametri separati non sembra fornire alcun beneficio. Ma alcune persone hanno paura di perdere IQueryable, quindi YMMV.

    
risposta data 31.05.2017 - 13:28
fonte

Leggi altre domande sui tag