winform validate c# validation nxbre

c# - validate - ¿Qué usarías para una capa de validación empresarial?



validate text c# (9)

En mi proyecto, necesito crear una capa de validación de objetos comerciales que tomará mi objeto y lo ejecutará contra un conjunto de reglas y devolverá el pase o el error y su lista de razones de falla. Sé que hay bastantes opciones para lograr esto.

De Microsoft:

Fuente abierta:

¿Alguien ha tenido éxitos o fallas particularmente grandes con cualquiera de estas tecnologías (o cualquiera de las que no mencioné) o cualquier opinión sobre lo que consideran más adecuado para la validación de reglas comerciales?

Editar: no solo estoy preguntando acerca de la longitud de cadena de validaciones genéricas <200, el código postal es de 5 dígitos o 5 + 4, sino que supongo que el motor de reglas se aprovechará realmente.

Debo admitir que, para validaciones realmente simples, tiendo a escribir mi propio motor de reglas muy pequeño y compacto, principalmente porque creo que usar la implementación de otra persona no vale la pena para un proyecto pequeño.

Enterprise Library Validation Block proporciona un enfoque muy similar a AOP y simplifica las cosas en 3.1 y 4.1 según mi experiencia.

La decisión de code-versus-rules-engine es una cuestión de intercambios, en mi humilde opinión. Algunos ejemplos son:

Ventajas del código

  • Potencialmente mayor rendimiento.
  • Utiliza las habilidades existentes de los desarrolladores.
  • No hay necesidad de herramientas separadas, motores en tiempo de ejecución, etc.

Ventajas del motor de reglas

(Las características varían en los distintos motores de reglas).

  • Regla DSL que es escribible (o al menos legible) por los usuarios comerciales.
  • Propiedades de fecha de vigencia y caducidad que permiten la programación automática de las reglas.
  • Los informes flexibles del depósito de reglas permiten un mejor análisis y auditoría del comportamiento del sistema.
  • Así como los motores de base de datos aíslan el contenido de datos / problemas de relación del resto del sistema, los motores de reglas aíslan la validación y la política del resto del sistema.

Experimenté con Workflow Foundation, utilicé EntLib y escribí mi propio motor de reglas.

En aplicaciones pequeñas donde realmente solo necesito hacer una validación basada en la IU para asegurarme de que los datos no válidos no entren en la base de datos, busco el bloque de validación de EntLib. Es fácil de usar y solo requiere una cantidad mínima de código en los objetos de mi dominio, además de no estropear NHibernate ni nada más en mi paquete de tecnología.

Para cosas complejas, validación de capa de dominio, etc., fácilmente optaría por escribir mi propio motor de reglas de nuevo. Prefiero escribir reglas en código, cada regla en su propia clase pequeña, fácilmente comprobable y muy simple para componer conjuntos complejos de reglas.

En la gran aplicación en la que trabajé donde escribí este tipo de motor de reglas, utilizamos FitNesse para probar nuestras configuraciones de reglas. Fue genial tener ese tipo de herramienta para utilizar para garantizar la corrección. Podríamos alimentarlo con tablas y tablas de datos y saber, con certeza, que nuestras reglas configuradas funcionaron.

Recomiendo usar el Marco CSLA . No solo para Validación sino también para otras características.

Una versión modificada de las reglas del marco CSLA.

Muchos de los otros motores de reglas tienen la promesa de que "El usuario final puede modificar las reglas para que se ajusten a sus necesidades".

Bahh. Muy pocos usuarios aprenderán las complejidades del formato del documento de reglas o podrán comprender las complejidades y las ramificaciones de sus cambios.

La otra promesa es que puede cambiar las reglas sin tener que cambiar el código. Yo digo que qué? Cambiar una regla incluso tan simple como "este campo no debe estar en blanco" puede tener un impacto muy negativo en la aplicación. Si esos campos donde anteriormente se permitía estar en blanco, ahora tiene una gran cantidad de datos no válidos en el almacén de datos. Además, las aplicaciones modernas se basan en la web o se distribuyen / actualizan a través de tecnologías como click = once. Entonces, actualizar dos componentes es tan fácil como actualizar un archivo de reglas.

Entonces, dado que el desarrollador los va a modificar de todos modos y porque son fundamentales para las operaciones de objetos comerciales, simplemente ubíquelos en un solo lugar y use el poder de los lenguajes y marcos modernos.

Tratar

http://rulesengine.codeplex.com

Es liviano, utiliza interfaces fluidas para definir la lógica de validación, extensible y ¡Gratis! Incluso puede definir reglas sobre interfaces, los implementadores heredan las reglas.

No más validación de estilo de atributo molesto - lo que no posee la clase que desea validar

Tiene un complemento para Asp.Net MVC (solo en el lado del servidor).

¡También hay otro proyecto llamado Polymod.Net que usa RulesEngine para proporcionar UI autovalidantes como se muestra en la captura de pantalla!

Realmente no me gustaban los bloques de reglas y validación provistos por Microsoft (demasiado complejos e inflexibles), así que tuve que construir los míos, basados ​​en la experiencia con motores de flujo de trabajo de negocios personalizados.

Después de un par de iteraciones, el proyecto finalmente se ha convertido en Open Source ahora (licencia BSD) y ha demostrado ser útil en los sistemas de producción. Características principales de .NET Application Block para validación y reglas comerciales :

  • Simple para empezar
  • Reglas para los objetos de dominio
  • Reutilización de reglas
  • Reglas de validación predefinidas
  • Comportamiento extensible
  • Anidación adecuada de objetos
  • Diseñado para la validación del nivel de DDD y UI
  • Múltiples niveles de informes
  • Producción a prueba y desarrollo activo
  • Base de código pequeña
  • Fuente abierta

Así es como se ve un enlace simple de reglas en el nivel de UI:

Tenga en cuenta que la implementación actual no tiene DSL en este momento. La sintaxis de C # es lo suficientemente expresiva por sí misma, por lo que no ha habido demanda para agregar DSL basado en Boo en la parte superior.