patrón Repositorio: Agregar elemento

Question

sólo tiene que aclarar éste, Si tengo la interfaz de abajo

public interface IRepository<T> 
{ 
    T Add(T entity); 
} 

cuando ésta se aplique, no la comprobación de la duplicación si la entidad ya existe antes de que persisten todavía es un trabajo de la Repositorio, o debería manejar en otro lugar?

Answer 1

Sí - Recomiendo hacer estas comprobaciones en el repositorio.

Respuesta larga: El término "repositorio" es un poco vago, pero se usa cada vez más como el nombre de la capa de abstracción de persistencia. El nombre es bueno, pero no dice demasiado: si toma Asp.Net MVC como ejemplo, las aplicaciones de muestra, como la cena de Neirds y similares, o los proyectos codeplex encapsulan el acceso a los datos por la clase de repositorio. Si dicha capa se implementa con una base de datos relacional para la instancia, las claves primarias de las tablas no permitirán entradas duplicadas, lo que significa que en este caso la implementación del repositorio generará una excepción si se insertan 2 entradas con la misma clave. Entonces, en otras palabras, una implementación RDBMS de un repositorio siempre lo hará debido a esta comprobación, no podrás evitarlo. Entonces, para que el comportamiento de los repositorios esté en el mundo más similar y para evitar sorpresas, permita que todos hagan este control.

Es una segunda pregunta si debe mantener en la lógica comercial ya que su método Add() no está alineado con una entrada que ya existe. A veces tiene sentido resolver esto solo en un punto, la base de datos, por ejemplo, debido a problemas de simultaneidad o ahorros de ida y vuelta. Por otro lado, es bueno decirle al usuario lo antes posible que ya se tomó un nombre de usuario. Entonces esto depende.

tienen un buen día

Answer 2

Si la entidad ya existe, puede lanzar una excepción o actualizar los campos de la entidad existente.

Si elige este último, el método probablemente debería llamarse algo así como AddOrUpdate()

LINQ to SQL de ejemplo

Si estoy Recuperación de un solo registro, voy a utilizar

public Entity GetEntity(int entityID) 
{ 
    return dataContext.Entities.SingleOrDefault(e => e.EntityID = entityID); 
} 

... Y en el método de llamada, verificaré si lo que se devuelve es nulo antes de intentar usar la entidad devuelta.

Si estoy actualizando un registro, recuperaré la entidad como se muestra, editaré la entidad y luego llamaré a un método de depósito UpdateEntity(entityID) para actualizar los campos en la base de datos.

Si agrego un registro, es aún más fácil. Dado que esta es una base de datos, y mis tablas contienen siempre un campo de identidad de tipo int (un número de auto-asignable, fundamentalmente), la adición de un registro es la operación más simple de todos (es siempre un nuevo registro):

Public void InsertEntity(Entity entity) 
{ 
    dataContext.Entities.InsertOnSubmit(entity); 
    dataContext.SubmitChanges(); 
} 

Las reglas comerciales (por ejemplo, las direcciones de correo electrónico son únicas) pueden manejarse en el repositorio o en una capa comercial separada. Si está buscando la forma más "correcta", creo que la mayoría de la gente estaría de acuerdo en que las reglas comerciales pertenecen a su propia capa de lógica de negocios.

Answer 3

Esencialmente, la decisión sobre dónde gestionar el caso depende de sus necesidades.

Si tiene reglas de negocio que definen las acciones de borrado para cuando esto sucede, por ejemplo, si existe un duplicado, el nuevo elemento debe renombrarse, y luego puede incorporarse a la clase de repositorio.

Por otro lado, si existen reglas más complejas donde, por ejemplo, se necesita más información para cambiar el artículo antes de agregarlo, entonces debe manejarse más arriba en la cadena alimentaria.

El concepto de repositorio indica que existe para realizar las actividades de persistencia. Entonces, si puedes hacerlo todo dentro del repositorio, está bien. Si descubre que comienza a hacer referencia fuera del repositorio, o su repositorio tiene dependencias, por ejemplo, llamando a otro repositorio, o un servicio, o un administrador (o la nomenclatura de procesador que prefiera), entonces es una buena señal dar un paso atrás.