Repositorio de Métodos vs Extender IQueryable

He estado pensando mucho en esto últimamente, después de comenzar en mi trabajo actual. Estoy acostumbrado a los repositorios, van por el camino IQueryable completo usando solo repositorios básicos como usted sugiere.

Siento que el patrón de repo es sólido y hace un trabajo semi-efectivo al describir cómo desea trabajar con los datos en el dominio de la aplicación. Sin embargo, el problema que está describiendo definitivamente ocurre. Se vuelve desordenado, rápido, más allá de una simple aplicación.

¿Hay, tal vez, formas de repensar por qué está pidiendo los datos de tantas maneras? Si no, realmente siento que un enfoque híbrido es la mejor manera de hacerlo. Crea métodos de repo para las cosas que reutilizas. Cosas para las que realmente tiene sentido. SECO y todo eso. Pero los one-offs? ¿Por qué no aprovechar IQueryable y las cosas sexys que puedes hacer con él? Es tonto, como dijiste, crear un método para eso, pero no significa que no necesites los datos. SECO no se aplica realmente allí ¿verdad?

Tomaría disciplina para hacer esto bien, pero realmente creo que es un camino apropiado.

Me doy cuenta de que esto es viejo, pero he estado lidiando con este mismo problema últimamente, y llegué a la misma conclusión que Chad: con un poco de disciplina, un híbrido de métodos de extensión y métodos de repositorio parece funcionar mejor.

Algunas reglas generales que he estado siguiendo en mi aplicación (Entity Framework):

Ordenar consultas

Si el método se usa solo para ordenar, prefiero escribir métodos de extensión que operan en IQueryable<T> o IOrderedQueryable<T> (para aprovechar el subyacente proveedor.) por ejemplo,

public static IOrderedQueryable<TermRegistration> ThenByStudentName(
    this IOrderedQueryable<TermRegistration> query)
{
    return query
        .ThenBy(reg => reg.Student.FamilyName)
        .ThenBy(reg => reg.Student.GivenName);
}

Ahora puedo usar ThenByStudentName() según sea necesario dentro de mi clase de repositorio.

Consultas que devuelven instancias individuales

Si el método implica consultar por parámetros primitivos, generalmente requiere un ObjectContext y no se puede hacer fácilmente static. Estos métodos los dejo en mi repositorio, por ejemplo,

public Student GetById(int id)
{
    // Calls context.ObjectSet<T>().SingleOrDefault(predicate) 
    // on my generic EntityRepository<T> class 
    return SingleOrDefault(student => student.Active && student.Id == id);
}

Sin embargo, si el método en su lugar implica consultar un EntityObject usando sus propiedades de navegación , generalmente se puede hacer static muy fácilmente, e implementado como un método de extensión. por ejemplo,

public static TermRegistration GetLatestRegistration(this Student student)
{
    return student.TermRegistrations.AsQueryable()
        .OrderByTerm()
        .FirstOrDefault();
}

Ahora puedo escribir convenientemente someStudent.GetLatestRegistration() sin necesidad de una instancia de repositorio en el ámbito actual.

Consultas que devuelven colecciones

Si el método devuelve algunos IEnumerable, ICollection o IList, entonces me gusta hacerlo static si es posible, y dejarlo en el repositorio incluso si usa propiedades de navegación. por ejemplo,

public static IList<TermRegistration> GetByTerm(Term term, bool ordered)
{
    var termReg = term.TermRegistrations;
    return (ordered)
        ? termReg.AsQueryable().OrderByStudentName().ToList()
        : termReg.ToList();
}

Esto es porque mis métodos GetAll() ya está en vivo en el repositorio, y ayuda a evitar un desorden desordenado de métodos de extensión.

Otra razón para no implementar estos "getters de colección" como métodos de extensión es que requerirían nombres más detallados para ser significativos, ya que el tipo devuelto no está implícito. Por ejemplo, el último ejemplo sería GetTermRegistrationsByTerm(this Term term).

Espero que esto ayude!

Seis años más tarde, estoy seguro de que @Alex ha resuelto su problema, pero después de leer la respuesta aceptada, quería agregar mis dos centavos.

El propósito general de extender IQueryable colecciones en un repositorio para proporcionar flexibilidad y capacitar a sus consumidores para personalizar la recuperación de datos. Lo que Alex ya ha hecho es un buen trabajo.

El papel principal de una capa de servicio es adherirse al principio separación de preocupaciones y abordar lógica de comandos asociado con la función de negocio.

En aplicaciones del mundo real, la lógica de consulta a menudo no necesita extensión más allá de la mecánica de recuperación proporcionada por el propio repositorio (ej. alteraciones de valor, conversiones de tipo).

Considere los dos escenarios siguientes:

IQueryable<Vehicle> Vehicles { get; }

// raw data
public static IQueryable<Vehicle> OwnedBy(this IQueryable<Vehicle> query, int ownerId)
{
    return query.Where(v => v.OwnerId == ownerId);
}

// business purpose
public static IQueryable<Vehicle> UsedThisYear(this IQueryable<Vehicle> query)
{
    return query.Where(v => v.LastUsed.Year == DateTime.Now.Year);
}

Ambos métodos son extensiones de consulta simples, pero por sutiles que sean, tienen diferentes roles. El primero es un filtro simple, mientras que el segundo implica necesidad de negocio (ej. mantenimiento o facturación). En un simple aplicación uno podría implementar ambos en un repositorio. En un sistema más idealista, UsedThisYear es el más adecuado para la capa de servicio (e incluso puede implementarse como un método de instancia normal) donde también puede facilitar mejor CQRS la estrategia de separar comandos y consultas.

Consideraciones principales son: (a) el propósito principal de su repositorio y (b) ¿cuánto le gusta a adherirse a CQRS y DDD filosofías.