2010-03-02 11 views
7

La validación de Business Objects es un problema común, pero existen algunas soluciones para resolverlo.¿Deben validarse los objetos de negocio o las entidades?

Una de estas soluciones es utilizar el marco NHibernate.Validator independiente, que es un marco de validación basado en atributos.

Pero estoy enfrentando una preocupación conceptual. Los validadores de atributos como NH.Validator son geniales, pero la validación solo se realiza cuando save-update-delete dentro de la Session.

Entonces, me pregunto si los objetos comerciales no deberían validarse a sí mismos para mantener su propia integridad y consistencia.

Respuesta

10

mi humilde opinión - hay 2 pasos de validaciones necesarias para un objeto de negocio (BO)/Entidad de ser válida:

Paso 1: BO/Entidad autovalidación - En esto, compruebe si el entidad es válida en términos de su estado F.Ex .: si el código postal está establecido, entonces tiene los caracteres válidos & es de longitud válida etc. forman las validaciones de nivel de BO/entidad. Pero más allá de este nivel de validación, no podríamos decir que el BO/Entity es válido en su dominio comercial y/o repositorio. Normalmente, la BO/entidad podría hacer cumplir este nivel de validación.

Paso 2: Contexto de validación - En esto, necesitamos validar si el BO/Entidad es válida en el contexto del repositorio donde se está persistió. F.Ex .: Es el código postal válido para el país en el que se realiza/envía el pedido, etc. Para esta validación, algunas o todas las entidades en el contexto actual podrían necesitar participar para asegurarse de que el BO/entidad es válida.

Por lo tanto, para mantener las entidades puras, deberá dividir la validación en estos 2 pasos: uno realizado por la propia entidad & el segundo por el repositorio que está persistiendo/trabajando con la entidad.

HTH.

+0

Esta separación de los dos pasos es interesante. Si bien nunca lo pensé de esta manera, uso parcialmente este enfoque sin saberlo. Aún así, trato de separar también la autovalidación de las entidades. Le expliqué cómo lo hice con el bloque de aplicación de validación aquí: http://stackoverflow.com/questions/2258513/validation-framework-in-net-that-can-do-edits-between-fields/2259062#2259062. – Steven

6

Sin embargo, no siempre es posible para ellos validar por sí mismos. ¿Qué pasa si ingresas un código postal "inválido"? Puede validar que el Código postal debe estar en un formato específico, pero ¿qué sucede si desea que sean "válidos", es decir, "existentes y que coincidan con la ciudad"? ¿O qué pasa si solo acepta números de teléfono de ciertos códigos de área y la lista de códigos válidos está en una base de datos mantenida por el departamento legal?

Si puede realizar la validación semántica, eso es genial y podría entrar en la clase ejecutiva. Pero a menudo, es posible que necesite validación adicional que simplemente no es posible manejar por la clase de negocios en sí, pero debe ser manejada por la clase que habla con la base de datos y otros servicios externos.

+0

+1 Tienes razón. En mi explicación, hablo de validaciones que las entidades pueden verificar por sí mismas. – Javier

+2

Estoy de acuerdo. Prefiero mantener mi lógica de validación separada de las entidades comerciales. – Steven

2

No sé si estamos hablando de la misma idea, pero si lo somos, me gusta lo que explicas. Muy rápido, explicaré lo que hago para resolver esto. En mi caso, todos los objetos bussines en mi capa de dominio deben anular dos métodos:

Obviamente, para mantener esto, tengo más clases implicadas, pero no escribiré todas aquí, porque solo estoy tratando de explicar el concepto

List<ValidationRule> notPassedValidationRules = new List<ValidationRule>(); 

//... 

public override void ValidateErrorsWhenSaving(Validator validator) 
{ 
    //... 
} 

public override void ValidateErrorsWhenDelete(Validator validator) 
{ 
    //... 
}   

En estos métodos, puedo comprobar para algunas condiciones booleanas, manteniendo un conjunto de reglas que no pasaron. En mi caso, estos métodos se invocan antes de que Unit Of Work confirme los cambios (inserte nuevas entidades, actualice, elimine) y muestre los posibles errores al usuario antes de comprometerse.

Cuestiones relacionadas