Comandos de consulta y / o especificaciones bien diseñados

Mi manera de lidiar con eso es en realidad simplista y agnóstica. Mi punto de vista para un repositorio es este: El trabajo del repositorio es proporcionar a la aplicación el modelo requerido para el contexto, por lo que la aplicación solo le pregunta al repositorio qué quiere, pero no le dice cómo obtenerlo.

Proporciono al método repository un Criterio (sí, estilo DDD), que será utilizado por el repositorio para crear la consulta (o lo que sea necesario, puede ser una solicitud de servicio web). Se une y los grupos en mi humilde opinión son detalles de cómo, no el qué y un criterio debe ser solo la base para construir una cláusula where.

Modelo = el objeto final o la estructura de datos neede por la aplicación.

public class MyCriteria
{
   public Guid Id {get;set;}
   public string Name {get;set;}
    //etc
 }

 public interface Repository
  {
       MyModel GetModel(Expression<Func<MyCriteria,bool>> criteria);
   }

Probablemente pueda usar el criterio OR (Nhibernate) directamente si lo desea. La implementación del repositorio debe saber cómo usar los Criterios con el almacenamiento subyacente o DAO.

No conozco su dominio y los requisitos del modelo, pero sería extraño si la mejor manera es que la aplicación para construir la consulta en sí. El modelo cambia tanto que no se puede definir algo estable?

Esta solución claramente requiere algún código adicional, pero no acopla el resto a un OR o lo que sea que esté utilizando para acceder al almacenamiento. El repositorio hace su trabajo para actuar como una fachada y IMO está limpio y el código 'criteria translation' es reutilizable

He hecho esto, soportado esto y deshecho esto.

El mayor problema es este: no importa cómo lo hagas, la abstracción añadida no te da independencia. Se filtrará por definición. En esencia, estás inventando una capa completa solo para hacer que tu código se vea lindo... pero no reduce el mantenimiento, mejora la legibilidad ni te gana ningún tipo de modelo de agnosticismo.

La parte divertida es que respondiste a tu propia pregunta en respuesta a la respuesta de Olivier: "esto es esencialmente duplicar la funcionalidad de Linq sin todos los beneficios que obtienes de Linq".

Pregúntate: ¿cómo no podría ser?

Puede utilizar una interfaz fluida. La idea básica es que los métodos de una clase devuelven la instancia actual esta misma clase después de haber realizado alguna acción. Esto le permite encadenar llamadas a métodos.

Al crear una jerarquía de clases apropiada, puede crear un flujo lógico de métodos accesibles.

public class FinalQuery
{
    protected string _table;
    protected string[] _selectFields;
    protected string _where;
    protected string[] _groupBy;
    protected string _having;
    protected string[] _orderByDescending;
    protected string[] _orderBy;

    protected FinalQuery()
    {
    }

    public override string ToString()
    {
        var sb = new StringBuilder("SELECT ");
        AppendFields(sb, _selectFields);
        sb.AppendLine();

        sb.Append("FROM ");
        sb.Append("[").Append(_table).AppendLine("]");

        if (_where != null) {
            sb.Append("WHERE").AppendLine(_where);
        }

        if (_groupBy != null) {
            sb.Append("GROUP BY ");
            AppendFields(sb, _groupBy);
            sb.AppendLine();
        }

        if (_having != null) {
            sb.Append("HAVING").AppendLine(_having);
        }

        if (_orderBy != null) {
            sb.Append("ORDER BY ");
            AppendFields(sb, _orderBy);
            sb.AppendLine();
        } else if (_orderByDescending != null) {
            sb.Append("ORDER BY ");
            AppendFields(sb, _orderByDescending);
            sb.Append(" DESC").AppendLine();
        }

        return sb.ToString();
    }

    private static void AppendFields(StringBuilder sb, string[] fields)
    {
        foreach (string field in fields) {
            sb.Append(field).Append(", ");
        }
        sb.Length -= 2;
    }
}

public class GroupedQuery : FinalQuery
{
    protected GroupedQuery()
    {
    }

    public GroupedQuery Having(string condition)
    {
        if (_groupBy == null) {
            throw new InvalidOperationException("HAVING clause without GROUP BY clause");
        }
        if (_having == null) {
            _having = " (" + condition + ")";
        } else {
            _having += " AND (" + condition + ")";
        }
        return this;
    }

    public FinalQuery OrderBy(params string[] fields)
    {
        _orderBy = fields;
        return this;
    }

    public FinalQuery OrderByDescending(params string[] fields)
    {
        _orderByDescending = fields;
        return this;
    }
}

public class Query : GroupedQuery
{
    public Query(string table, params string[] selectFields)
    {
        _table = table;
        _selectFields = selectFields;
    }

    public Query Where(string condition)
    {
        if (_where == null) {
            _where = " (" + condition + ")";
        } else {
            _where += " AND (" + condition + ")";
        }
        return this;
    }

    public GroupedQuery GroupBy(params string[] fields)
    {
        _groupBy = fields;
        return this;
    }
}

Lo llamarías así{[20]]}

string query = new Query("myTable", "name", "SUM(amount) AS total")
    .Where("name LIKE 'A%'")
    .GroupBy("name")
    .Having("COUNT(*) > 2")
    .OrderBy("name")
    .ToString();

Solo puede crear una nueva instancia de Query. Las otras clases tienen un constructor protegido. El punto de la jerarquía es "desactivar" los métodos. Por ejemplo, el método GroupBy devuelve un GroupedQuery que es la clase base de Query y no tiene un método Where (el método where se declara en Query). Por lo tanto, no es posible llamar Where después de GroupBy.

Sin embargo, no es perfecto. Con esta jerarquía de clases puede ocultar sucesivamente miembros, pero no mostrar otros nuevos. Por lo tanto Having lanza una excepción cuando se llama antes de GroupBy.

Tenga en cuenta que es posible llamar a Where varias veces. Esto añade nuevas condiciones con un AND a las condiciones existentes. Esto hace que sea más fácil construir filtros programáticamente a partir de condiciones individuales. Lo mismo es posible con Having.

Los métodos que aceptan listas de campos tienen un parámetro params string[] fields. Le permite pasar nombres de campo individuales o una matriz de cadenas.

Las interfaces Fluent son muy flexibles y no requieren que cree una gran cantidad de sobrecargas de métodos con diferentes combinaciones de parámetros. Mi ejemplo funciona con cadenas, sin embargo, el enfoque se puede extender a otros tipos. También puede declarar métodos predefinidos para casos especiales o métodos que aceptan tipos personalizados. También puede agregar métodos como ExecuteReader o ExceuteScalar<T>. Esto le permitiría definir consultas como esta

var reader = new Query<Employee>(new MonthlyReportFields{ IncludeSalary = true })
    .Where(new CurrentMonthCondition())
    .Where(new DivisionCondition{ DivisionType = DivisionType.Production})
    .OrderBy(new StandardMonthlyReportSorting())
    .ExecuteReader();

Incluso los comandos SQL construidos de esta manera pueden tener parámetros de comando y así evitar problemas de inyección SQL y al mismo tiempo permitir que los comandos sean almacenados en caché por el servidor de base de datos. Esto no es un reemplazo para un O / R-mapper, pero puede ayudar en situaciones en las que crearía los comandos usando concatenación de cadena simple de lo contrario.