dónde poner la lógica de validar? En servicio o repositorio?

Question

Tengo una lógica como esta, antes de guardar el stock en el db, verificará si hay stock con el mismo código de stock en la base de datos. Mi pregunta es dónde debería poner la lógica, en la capa de servicio o en la capa de repositorio. aquí es el código de ejemplo:
la opción 1: poner en la capa de servicio, pongo el Método IsAccountAlreadyExists en la capa de servicio

public override void Save(AccountInfo accountInfo) 
{ 
    using (var scope = new TransactionScope()) 
    { 
     if(this.IsAccountAlreadyExists(accountInfo)) 
     { 
      throw new AccountAlreadyExistedException(
       "Account Code : " + accountInfo.AccountCode + 
       " already existed."); 
     } 

     accountRepository.Save(accountInfo); 
      scope.Complete(); 
    } 
} 

opción 2: Voy a mover las IsAccountAlreadyExists lógica a la capa de repositorio.

public override void Save(AccountInfo accountInfo) 
{ 
    try 
    { 
     using (var scope = new TransactionScope()) 
     { 
      accountRepository.Save(accountInfo); 
      scope.Complete(); 
     } 
    } 
    catch(AccountAlreadyExistedException e) 
    { 
     ... 
    } 
} 

¿cuál es su opinión?

Answer 1

Dado que ha pedido sus opiniones, aquí está. :-) Coloque la lógica de validación en la capa más cercana a los datos. Entonces, en este caso, la lógica debería estar en el Repositorio. El Servicio puede atrapar la excepción y traducirla, si así lo desea. Pero el criterio de que "Las cuentas deben ser únicas" es una característica del Repositorio, IMO.

Answer 2

Lo pondría en la capa de servicio. El repositorio maneja la lógica de persistencia.

Es responsabilidad del servicio llamar a otros objetos para realizar el trabajo.

Answer 3

Prefiero poner cheques más cerca de los datos, por lo que en este caso esa sería la base de datos.

Haría una restricción única en función de las condiciones que está realizando para garantizar que la cuenta no exista. Esto aseguraría que nadie pueda pasar por alto mi nivel intermedio e insertar datos incorrectos.

Luego puedo poner el cheque en la capa de repositorio como una precaución adicional.

Answer 4

Servicio - Los patrones de repositorio pueden ser un poco subjetivos. Por supuesto, hay ejemplos malos/completamente incorrectos (este no es), pero la mayoría de las veces, se trata de preferencias personales.

El patrón que tiendo a seguir es que la capa de repositorio debe estar 99% dedicada a las operaciones de lectura-escritura-eliminación con su origen de datos. La única validación que realiza mi capa de repositorio es la validación a muy bajo nivel en los modelos: esto se hace típicamente a través de un método Model.IsValid. Comprueba únicamente los campos obligatorios y el formato/contenido básico de esos campos (por ejemplo, una comprobación reg-ex de un campo que se supone que debe contener y enviar por correo electrónico). La capa de repositorio no intenta dar sentido a estos errores: si el modelo no es válido, arroja una excepción y eso termina su manejo.

Las comprobaciones de lógica de negocios deben realizarse en la capa de servicio. Si se permite que los objetos del Usuario se 'asignen' a un Modelo en particular ("Joe posee el registro X"), la capa de servicio debe realizar las comprobaciones para asegurarse de que Joe tenga ese registro, etc. Para completar, mi capa de Servicio generalmente también comprueba el método IsValid en el modelo también, para adelantarse a las excepciones de la capa de datos.

Mi único comentario con su código de ejemplo es con el nombre del método "Guardar"; esto es demasiado ambiguo. Prefiero Crear/Insertar y Actualizar - está claro entonces que el anterior dará como resultado la creación de un nuevo registro (en la medida ocasional que sobreescribo el campo Id del objeto con un nuevo valor), mientras que el último debería actualizar un registro, y arrojaría una excepción si no se pasa ningún valor Id.

Answer 5

que consideran que se trata de tres niveles (con una interfaz definida para conectar cada pieza):

• repositorio de datos - sólo para almacenar y recuperar datos en bruto. Como poca lógica va aquí como sea posible.
• Modelo de negocio - toda la información va aquí, incluida la validación.
• Servicio (es decir, acceso de cliente): una pieza muy delgada, lo suficiente para proporcionar una conexión con el cliente.

De esta forma, si elige almacenar sus datos de alguna otra forma, la lógica de validación no se perderá con él.

Del mismo modo, si decide proporcionar una forma diferente de acceso de cliente, lo hace sin necesidad de replicar un montón de lógica.