¿Cómo podemos usar los procedimientos de almacenamiento y los tipos complejos al tratar con el patrón Repositorio en Entity Framework? ¿Alguien podría dar un ejemplo simple?¿Cómo usar el procedimiento de almacenamiento y los tipos complejos usando el patrón de repositorio en EF?
¿También en qué situación deberíamos realmente ir para un patrón de repositorio?
Gracias de antemano
patrones de depósito son importantes para desacoplar el mecanismo de almacenamiento de datos de la aplicación. Al hacer esto, es mucho más fácil probar la unidad o reemplazar la estructura de datos en una fecha posterior. Lea mi blog sobre cómo/por qué hago esto aquí: http://blog.staticvoid.co.nz/2011/10/staticvoid-repository-pattern-nuget.html
Personalmente, nunca uso procedimientos almacenados ya que realmente no los veo necesarios en la mayoría de los casos, pero para implementar esto con mi patrón de repositorio lo haría recomendamos que cree un nuevo RepositoryDataSource para mapearlo a su procedimiento almacenado y luego llame al procedimiento almacenado a través de EF o SQL de la vieja escuela. Recomendaría lanzar una excepción de algún tipo en la actualización o guardar.
EDITAR == (En respuesta a la pregunta '¿por qué capas 2') ==
La razón por la que he elegido para ir por dos capas es porque en mi mente un repositorio es tanto que ver con la forma en que obtener los datos (la capa de fuente de datos) y cómo presentar la capa (en mi implementación, tal vez un repositorio mal nombrado). Al dividir la implementación a la mitad, la forma en que puede permanecer igual independientemente del qué. por el contrario, si desea cambiar la forma en que puede hacerlo, mientras permanece solo débilmente acoplado al qué.
Por ejemplo, es posible que desee cambiar su fuente de datos EF por una versión en memoria. Esto no debería necesariamente cambiar la forma en que se presentan los datos a la aplicación.
Por otro lado es posible que desee almacenar en caché sus datos o, tal vez, registrar alguna información sobre el rendimiento de las escrituras en el almacén de datos. ¿Por qué debería importar qué mecanismo de almacenamiento real se usa debajo de las cubiertas?
Personalmente, he encontrado la división en este lugar en particular para hacer que la solución sea mucho más flexible.
Creo que se ha perdido un punto acerca de por qué las personas implementan el patrón de repositorio cuando EF ya implementa el patrón de repositorio a través de ObjectSet/DbSet?
La respuesta popular sería porque muchos tutoriales aconsejan que lo uses sin justificar las razones. Hay razones válidas para no usar Repository layer sobre ObjectSet/DbSet. Sin embargo, señalaré algunas razones de por qué es preferible.
Filtros predeterminados Hay muchas situaciones en las aplicaciones de la vida real en las que necesita un filtro predeterminado. Por ejemplo, los productos descontinuados no se venden. Si expone los Productos ObjectSet/DbSet directamente, habrá problemas si alguien olvida aplicar el filtro predeterminado. También evita la duplicación de la lógica. También puede modificar el filtro predeterminado más tarde sin interrumpir los problemas.
public IQueriable<Product> GetAll()
{
return context.Products.Where(p => !p.IsDiscontinued);
}
suave Elimina Muchas aplicaciones utilizan eliminaciones blandas en las que guarda una columna como IsDeleted sin tener que quitar la fila.Ahora el ObjectSet/DbSet tiene un método Delete, pero una vez que llame a este método asignará los valores null a las propiedades de FK que aceptan valores NULL. Puede que no quieras esto.
public void Delete(Product product)
{
// can apply any other logic here
product.IsDeleted = true;
}
Sólo Lectura Entidades Hay muchos situación en alguna otra aplicación está a cargo de la creación, eliminación y actualización de las entidades y su aplicación sólo se muestra la entidad. Pero ObjectSet/DbSet expone la funcionalidad no admitida en este caso. Otro beneficio en este caso sería usar la opción NoTracking para reducir el tiempo de materialización de la entidad.
Cambie el acceso a los datos sin exponer la implementación Hay ocasiones en que LINQ no es suficiente. Aquí puede usar SQL o SP sin formato. Tener un repositorio evitará exponer diferentes métodos de consulta/actualización cuando la funcionalidad expuesta por EF no es suficiente.
Trabajar con bases de datos existentes Cuando no puede darse el lujo de crear la base de datos que EF puede manejar. La tabla existente puede tener columnas Sql Variant, XML. Duplicación de entradas a otras tablas y un sinnúmero de otros casos que debe manejar para mantener la integridad de la base de datos.
Estas técnicas pueden no ser a prueba de balas, pero serán útiles si la situación así lo requiere. Lo que sugeriría es que, sin entrar directamente en los repositorios en los que es mejor pensar, agrega otra capa de abstracción necesaria para implementar las funcionalidades requeridas.
¿No es EF una abstracción sobre su almacenamiento? ¿Por qué necesitas envolverlo una vez más? ¿Qué prueba exactamente usted en un repositorio? –
@EstebanAraya: generalmente no pruebas los repositorios (pruebas de integración). Al inyectar una interfaz de repositorio, puede simular eso para probar otras clases (lógica comercial) independientemente de una base de datos. El simulacro puede devolver cualquier colección de POCO que necesiten sus pruebas. – TrueWill
EF es una abstracción que proporciona mapeo de objetos, seguimiento de entidad/cambio. El repositorio ajusta la lógica de negocio utilizada para acceder a los datos. La lógica como se describió en la respuesta de @ Eranga. es decir, consultar productos pero excluyendo productos descontinuados. Al usar el patrón de repositorio, se asegura de que se sigan siempre sus reglas de negocio al acceder a los datos subyacentes. – BZink