Try Catch in Repository

Ninguno de los ejemplos que he examinado para los patrones de repositorio incluye ningún tipo de manejo de errores. ¿Por qué es esto? Digamos, por ejemplo, tengo esto:Try Catch in Repository

public virtual TItem Insert<TItem>(TItem item) where TItem:class,new() 
    { 
     dbContext.Set<TItem>().Add(item); 
     try 
     { 
      dbContext.SaveChanges(); 
     } 
     catch (DbUpdateException) 
     { 

      return null; 
     } 

     return item; 

    }

Una instancia en la que infringimos una restricción. Capturo la DbUpdateException ... ¿Dónde manejaría este error en vivo si no está en el repositorio mismo?

Fuente

2011-04-06 Code Jammr

En su mayor parte, un repositorio no necesita preocuparse por el manejo de excepciones. Las clases que consumen los repositorios deberían manejar eso. En su ejemplo, ¿por qué querría devolver nulo si se produce un error de inserción? ¿No es menos claro que solo lanzar una excepción?

Por ejemplo, supongamos que queremos insertar un registro a través del repositorio y luego imprimir la nueva ID. Suponga que la inserción va a fallar por cualquier razón.

var myNewItem = myRepository.Insert(myItem); 
Console.WriteLine("MyItem added with ID: {0}", myNewItem.ID);

Siguiendo el patrón en su pregunta, se obtendría una excepción NullReference en la segunda línea si el Insert falla. Eso es un poco extraño. Es más claro ver el DbUpdateException en la primera línea. También es mejor poder contar con Insert siempre devolviendo una instancia válida o lanzando una excepción.

Fuente

2011-04-06 03:56:22 rsbarro

No tengo ningún problema con que arroje la excepción DbUpdate, es más limpio que el NullRefrence, estoy de acuerdo. De vuelta en el día del procedimiento sotrado que usaríamos si no existiera. Obviamente tengo constaints en el modelo de datos. Entonces, ¿cómo hacer que una entidad sea lo suficientemente inteligente como para buscar un registro antes de hacer una inserción? –

Un enfoque sería utilizar algún tipo de Validator antes de hacer la inserción para verificar las restricciones, de modo que pueda proporcionar mensajes de error amistosos. O podría atrapar las excepciones de restricción lanzadas por la base de datos en lo que sea que consuma el repositorio. De cualquier manera, no creo que sea el trabajo del repositorio averiguar si se puede insertar o no un registro. – rsbarro

Acepto, cruzaré ese puente cuando termine el código del repositorio y realmente conecte un DI para el consumidor. –

En un sistema diseñado adecuadamente, las restricciones nunca se deben violar. Haga que sus entidades sean más inteligentes: por ejemplo, no use incubadoras ciegas implementadas automáticamente.

El repositorio no es el lugar para hacer la validación de datos. El lugar correcto es:

Si está revisando simplemente restricciones "contractuales", p. "la cantidad debe ser un entero no negativo" o "no me pase un cliente nulo", coloque la lógica en la propia entidad (ya sea adaptadores o métodos de construcción o mutación, según corresponda).
Si está comprobando la lógica comercial, colóquela en objetos especializados (si lo desea, las especificaciones DDD) que abstraen esa lógica.

La única vez que estas excepciones deben llegar es al ejecutar sus ~~unidad~~ pruebas de integración y se obtiene un fracaso, que revelan que, o bien las limitaciones de su base de datos no coinciden con su entidad o su entidad se implementa de forma incorrecta . Entonces definitivamente no debería catch ellos.

Fuente

2011-04-06 03:41:04 Domenic

Respuesta

Cuestiones relacionadas