A Super Get Method in a Generic repository implementation, using Entity Framework. Source(s): http://blog.falafel.com/Blogs/AdamAnderson/adam-anderson/2014/02/28/the-four-deadly-sins-of-linq-data-access-part-2-too-many-columns http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patt…

GenericRepository<TEntity>

 
          ...
           // _repository is a GenericRepository<Villa>.
           
            var villas = _repository
               .Get(
                   q => q.Select(s => new VillaDto { 
                       Id = s.PodId, 
                       Name = s.Name, 
                       Price=s.Price, 
                       Location = s.Location }),
                   f => f.Location == "Punta Cana",
                   o => o.OrderBy(i => i.Price)
               );
       ...
       
       
        public IEnumerable<TResult> SuperGet<TResult>(
            Func<IQueryable<TEntity>, IQueryable<TResult>> transform,
            Expression<Func<TEntity, bool>> filter = null,
            Func<IQueryable<TResult>, IOrderedQueryable<TResult>> orderBy = null)
        {
            // _dbSet is DbSet<TEntity> property of a DbContext
            var query = (filter == null) ? _dbSet : _dbSet.Where(filter);

            var notSortedResults = transform(query);

            return orderBy == null ? (IEnumerable<TResult>) notSortedResults : orderBy(notSortedResults).ToList();
        }

Wilson, actualmente trabajo para una compania que distribuye productos de telefonicas y las cosas cambian muchas veces. Solo estoy yo en la parte Web y hay muchas cosas que la hacen con procedures porque el tiempo no me permite hacerlas. El factor comunicacion aqui es una basura y solo por eso los usamos.

Mira como llamo uno de los SP bajo el metodo que coloque mas arriba (omito el nombre real del SP y las propierdades :P):

//storeId es STRING, dateFrom es DateTime, dateTo es DateTime
using (UnitOfWork uow = new UnitOfWork())
{
    //Sps_ProcedimientoX_Result
    var result = uow.
                 GetProcedureRepository<ProcedureX_Result>().
                 ExecuteStoredProc<ProcedureXDTO>(x => x.Select(r => new ProcedureXDTO
                                                  {
                                                          Prop1 = r.Prop1,
                                                          Prop2 = r.Prop2,
                                                          Prop3 = r.Prop3,
                                                          ...
                                                  }), new object[] { storeId, dateFrom, dateTo });

    return result;
}

---

En la BD se ejecutaria lo siguiente:

EXEC ProcedureX @iStoreId = 'storeId', @iTxnDateFrom = 'dateFrom', @iTxnDateTo = 'dateTo'

No tengo que ocupar mi tiempo instanciando los object parameters :)

Oh ok, ya entiendo.. el transform es el mapper.. como con el ExecuteFunction se mapean las propiedades automaticamente de acuerdo al nombre.. no pense era necesario el transform.. pero eso de objectParameters si es un lio..^_^

Reflexion for the win! ^_^

Javier, haz el pull request para aceptar tu aporte en el repo.

No he realizado el Pull Request con el cambio porque se me queda en el trabajo :P Manana lo hago.

Tengo varias preguntas para ustedes dos. Si yo tengo 5 condiciones en el filtro pero son opcionales, como le hago para que en el Query que se ejecuta en la base de datos, las que son opcionales ni siquiera aparezcan en el WHERE? Pienso que es lo que hace falta ahora mismo.

A que te refieres cuando dices que tus condiciones son opcionales?

Puedes proveer un ejemplo concreto?