Entity Framework 6 Code First - ¿Es Buena la Implementación del Repositorio?

Lamento (no) decir que el codefizzle, el artículo de Dyksta y las respuestas anteriores son incorrectos. Por el simple hecho de que utilizan las entidades EF como objetos de dominio (negocio), que es un gran WTF.

Actualización : Para una explicación menos técnica (en palabras simples) lea Patrón de repositorio para Dummies

En pocas palabras, cualquier interfaz de repositorio no debe acoplarse a NINGÚN detalle de persistencia (persistence). La interfaz repo solo trata con objetos que tiene sentido para el resto de la aplicación (dominio, tal vez interfaz de usuario como en la presentación). Muchas personas (con MS liderando el paquete, con intención sospecho) cometen el error de creer que pueden reutilizar sus entidades EF o que pueden ser objeto de negocios encima de ellas.

Mientras que puede suceder, es bastante raro. En la práctica, tendrá muchos objetos de dominio 'diseñados' después de las reglas de la base de datos, es decir, un mal modelado. El propósito del repositorio es desacoplar el resto de la aplicación (principalmente el negocio capa) de su forma de persistencia.

¿Cómo desacoplarlo cuando su repositorio trata con entidades EF (detalle de persistencia) o sus métodos devuelven IQueryable, una abstracción filtrada con semántica incorrecta para este propósito (IQueryable le permite construir una consulta, lo que implica que necesita conocer los detalles de persistencia, negando así el propósito y la funcionalidad del repositorio)?

Un objeto domin nunca debe saber sobre persistencia, EF, joins, etc. No debería saber qué motor de base de datos eres usando o si estás usando uno. Lo mismo con el resto de la aplicación, si desea que sea desacoplado de los detalles de persistencia.

La interfaz del repositorio solo sabe lo que sabe la capa superior. Esto significa, que una interfaz de repositorio de dominio genérico se ve así

public interface IStore<TDomainObject> //where TDomainObject != Ef (ORM) entity
{
   void Save(TDomainObject entity);
   TDomainObject Get(Guid id);
   void Delete(Guid id);
 }

La implementación residirá en el DAL y utilizará EF para trabajar con la BD. Sin embargo, la implementación se ve así

public class UsersRepository:IStore<User>
 {
   public UsersRepository(DbContext db) {}


    public void Save(User entity)
    {
       //map entity to one or more ORM entities
       //use EF to save it
    }
           //.. other methods implementation ...

 }

Usted no tiene realmente un repositorio genérico concreto . El único uso de un repositorio genérico concreto es cuando cualquier objeto de dominio se almacena en forma serializada en una tabla tipo clave-valor. No es el caso de un OR.

¿Qué hay de las consultas?

 public interface IQueryUsers
 {
       PagedResult<UserData> GetAll(int skip, int take);
       //or
       PagedResult<UserData> Get(CriteriaObject criteria,int skip, int take); 
 }

El UserData es el modelo de lectura/vista adecuado para el uso del contexto de consulta.

Puede usar directamente EF para realizar consultas en un manejador de consultas si no le importa que su DAL conozca los modelos de vista y, en ese caso, no será necesidad de cualquier repo de consulta.

Conclusión

• Su objeto de negocio no debería saber acerca de las entidades EF.
• El repositorio utilizará un repository , pero nunca expone el OR al resto de la aplicación, por lo que la interfaz repo utilizará solo objetos de dominio o modelos de vista (o cualquier otro objeto de contexto de la aplicación que no sea un detalle de persistencia)
• No le dices al repo cómo hacer su trabajo, es decir, NUNCA uses IQueryable con un repo interfaz
• Si solo desea usar la base de datos de una manera más fácil/fresca y está tratando con una simple aplicación CRUD donde no necesita (asegúrese de ello) para mantener la separación de preocupaciones, entonces omita el repositorio todos juntos, use directamente EF para todos los datos. La aplicación estará estrechamente acoplada a EF, pero al menos cortarás al intermediario y será a propósito, no por error.

Tenga en cuenta que usar el repositorio de manera incorrecta, invalidará su uso y su la aplicación seguirá estando estrechamente acoplada a la persistencia (persistence).

En caso de que creas que el OR está ahí para almacenar mágicamente tus objetos de dominio, no lo está. El propósito de OR es simular un almacenamiento OOP sobre tablas relacionales. Tiene todo que ver con la persistencia y nada que ver con el dominio, así que no use el persistence outside persistence.

DbContext de hecho, se construye con la Unidad de patrón de trabajo. Permite que todas sus entidades compartan el mismo contexto mientras trabajamos con ellas. Esta implementación es interna a la DbContext.

Sin embargo, debe tenerse en cuenta que si instancias dos objetos DbContext, ninguno de ellos verá las entidades del otro que están rastreando. Están aislados unos de otros, lo que puede ser problemático.

Cuando compilo una aplicación MVC, quiero asegurarme de que durante el durante la solicitud, todo mi código de acceso a datos funciona a partir de un único DbContext. Para lograr eso, aplico la Unidad de Trabajo como un patrón externo a DbContext.

Aquí está mi unidad de objeto de trabajo de una aplicación de receta de barbacoa que estoy construyendo:

public class UnitOfWork : IUnitOfWork
{
    private BarbecurianContext _context = new BarbecurianContext();
    private IRepository<Recipe> _recipeRepository;
    private IRepository<Category> _categoryRepository;
    private IRepository<Tag> _tagRepository;

    public IRepository<Recipe> RecipeRepository
    {
        get
        {
            if (_recipeRepository == null)
            {
                _recipeRepository = new RecipeRepository(_context);
            }
            return _recipeRepository;
        }
    }

    public void Save()
    {
        _context.SaveChanges();
    }
    **SNIP**

Adjunto todos mis repositorios, que están inyectados con el mismo DbContext, a mi Unidad de objeto de Trabajo. Siempre y cuando los repositorios se soliciten desde la Unidad de objeto de trabajo, podemos estar seguros de que todos nuestros códigos de acceso a datos se gestionarán con la misma DbContext - salsa impresionante!

Si tuviera que usar esto en una aplicación MVC, me aseguraría de que la Unidad de Trabajo se use durante toda la solicitud instanciándola en el controlador y usándola durante todas sus acciones:

public class RecipeController : Controller
{
    private IUnitOfWork _unitOfWork;
    private IRepository<Recipe> _recipeService;
    private IRepository<Category> _categoryService;
    private IRepository<Tag> _tagService;

    //Using Dependency Injection 
    public RecipeController(IUnitOfWork unitOfWork)
    {
        _unitOfWork = unitOfWork;
        _categoryRepository = _unitOfWork.CategoryRepository;
        _recipeRepository = _unitOfWork.RecipeRepository;
        _tagRepository = _unitOfWork.TagRepository;
    }

Ahora en nuestra acción, podemos estar seguros de que todos nuestros códigos de acceso a datos usarán el mismo DbContext:

    [HttpPost]
    public ActionResult Create(CreateEditRecipeViewModel model)
    {
        Mapper.CreateMap<CreateEditRecipeViewModel, Recipe>().ForMember(r => r.IngredientAmounts, opt => opt.Ignore());

        Recipe recipe = Mapper.Map<CreateEditRecipeViewModel, Recipe>(model);
        _recipeRepository.Create(recipe);
        foreach(Tag t in model.Tags){
             _tagRepository.Create(tag); //I'm using the same DbContext as the recipe repo!
        }
        _unitOfWork.Save();

Buscando en Internet encontré esto http://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework/ es un artículo de 2 partes sobre la utilidad del patrón de repositorio por Jon Smith. La segunda parte se centra en una solución. Espero que ayude!

Repositorio con unidad de implementación de patrón de trabajo es una mala respuesta a su pregunta.

El DbContext de entity framework es implementado por Microsoft de acuerdo con la unidad de patrón de trabajo. Eso significa el contexto.SaveChanges guarda transaccionalmente tus cambios de una sola vez.

El DbSet es también una implementación del patrón del repositorio. No construyas repositorios que solo puedes hacer:

void Add(Customer c)
{
   _context.Customers.Add(c);
}

Crear un método de una sola línea para lo que puede hacer dentro de la servicio de todos modos ???

No hay beneficio y nadie está cambiando EFM a otro E hoy en día...

No necesitas esa libertad...

Chris Hardie está argumentando que podría haber varios objetos de contexto instanciados, pero ya haciendo esto lo haces mal...

Simplemente use una herramienta de IOC que le guste y configure el MyContext por solicitud Http y estará bien.

Tome ninject por ejemplo:

kernel.Bind<ITeststepService>().To<TeststepService>().InRequestScope().WithConstructorArgument("context", c => new ITMSContext());

El servicio que ejecuta la lógica de negocio obtiene contexto inyectado.

Simplemente mantenlo simple estúpido: -)

Debe considerar "objetos de comando / consulta" como una alternativa, puede encontrar un montón de artículos interesantes alrededor de esta área, pero aquí hay uno bueno:

Https://rob.conery.io/2014/03/03/repositories-and-unitofwork-are-not-a-good-idea /

Cuando necesite una transacción sobre varios objetos de la base de datos, utilice un objeto de comando por comando para evitar la complejidad del patrón UOW.

Un objeto de consulta por consulta es probablemente innecesario para la mayoría de los proyectos. En su lugar podría elija comenzar con un objeto 'FooQueries' } con lo que quiero decir que puede comenzar con un patrón de Repositorio para LECTURAS, pero nombrarlo como "Consultas" para ser explícito de que no hace y no debe hacer ningún insert/updates.

Más tarde, podría encontrar que vale la pena dividir objetos de consulta individuales si desea agregar cosas como autorización y registro, podría alimentar un objeto de consulta en una canalización.

Siempre uso UoW con el código EF primero. Me parece más eficiente y más fácil de manejar sus contextos, para evitar fugas de memoria y tal. Puedes encontrar un ejemplo de mi solución alternativa en mi github: http://www.github.com/stefchri en el proyecto RADAR.

Si tiene alguna pregunta al respecto, siéntase libre de preguntársela.