/ / EF 4.0 Repositorio patrón IList <T> o IEnumerable <T> - entidad-marco-4

Patrón de repositorio EF 4.0 IList <T> o IEnumerable <T> - entity-framework-4

Me fijé en las implementaciones comunes del patrón de Repositorio EF en la web. Entonces vine con tal pregunta. Por ejemplo, si tengo un método como ese:

    public IEnumerable<Entity> FindEntity(Expression<Func<Entity, bool> where) {...}

Que si tengo un caso donde necesito tener IList en lugar de IEnumarable

Puedo crear IList basado en mi implementación de IEnumerable FindEntity

    IList<Entity> myList = new List<Entity>(FindEntity(x = x => x.Date == inputDate));

Entonces puedo tener todas las ventajas de la interfaz IList (Count, etc ...) en la instancia de myList.

¿Es este un buen enfoque para hacer eso o puede haber mejores formas de lanzar IEnumerable a IList o también como opción i puede tener un método adicional en el Repositorio que devuelve IList por defecto, por ejemplo.

    public IList<Entity> FindEntity(Expression<Func<Entity, bool> where) {....}

en ese caso, puedo eliminar la implementación de IEnumerable FindEntity porque simplemente puedo convertir IList a IEnumerable cuando lo necesito, o puedo vivir ambas implementaciones para evitar cualquier conversión.

Y una pregunta más: ¿Por qué la práctica común de implementación de Repository tiene solo IEnumerable no IList, debería haber una explicación para eso? ¿O son solo las preferencias personales?

Sí entiendo que IEnumerable es mucho másmás ligero en lugar de IList, pero de todos modos hay muchas situaciones en las que necesitamos tener IList en lugar de IEnumerable y, en este enfoque, debemos lanzar IEnumerable a IList, ¿no es así?

Respuestas

0 para la respuesta № 1

Creo que es una opción. IEnumerable es el mínimo denominador común para una colección. También puedes foreach y escribir sentencias linq. Al estar más arriba en la capa, ICollection o Ilist exponen más características que tal vez no quiera permitir, como agregar algo a la colección, eliminar cosas así.