Uso del patrón de Especificación

Question

Al igual que cualquier patrón de diseño del patrón Especificación es un gran concepto, pero susceptibles a abusar por un arquitecto ansiosos / desarrollador.

Estoy a punto de desarrollo comenzará en una nueva aplicación (.NET y C #) y me gusta mucho el concepto del modelo de especificación y estoy dispuesto a hacer pleno uso de ella. Sin embargo antes de entrar en todas las armas de fuego ardiente que estaría muy interesado en saber si alguien puede compartir los puntos de dolor que experimentaron cuando el uso de la especificación pattern en el desarrollo de una aplicación.

Lo ideal es que estoy buscando para ver si otros han tenido problemas en

• pruebas de unidad de escritura contra el patrón especificación
• La decisión de qué capa de las especificaciones deben vivir en (repositorio de información, servicio de dominio, etc)
• Su uso por todas partes cuando una simple declaración if habría hecho el trabajo
• etc?

Gracias de antemano

Answer 1

Como David señaló en su comentario, mucho de lo que es útil sobre la especificación ahora se puede lograr de forma más sucinta con los gustos de LINQ.

En lugar de un nuevo tipo de especificación, puede crear especificaciones arbitrarias sobre la marcha: GetCustomers().Where(customer => customer.IsActive && customer.City == "Oakland");

Esto no es un reemplazo completo para la especificación, sin embargo, por un par de razones:

1. El / filtrado de clasificación que ocurre en la clase que consume después de regresar a todos los clientes. Si se trata de otra cosa que no sea objetos en memoria, esto es subóptima (LINQ a SQL y similares son excepciones porque se compilan y consultas optimizar y ejecutarlos en el / lado remoto del servidor, volviendo sólo los resultados deseados ).
2. El API es muy abierto a cualquier consulta si expone colecciones y salir de la especificación de las consultas LINQ. Si desea limitar qué o cuánto se puede recuperar, se necesita un conjunto de especificaciones con el que consulta.

Ciertamente, no hay necesidad de usarlo en todas partes, y es muy posible que usted no lo necesita en absoluto; No sé su dominio o lo que está trabajando.

Creo que el mejor consejo es no mirada para utilizarlo. Vas a ver cuando se justifica, más probable es que al comenzar a escribir una clase que se ve como el primer ejemplo en el artículo al que se conectó.

Hemos de tener en su repositorio patrón mental, por lo que tiene, si lo necesita; si nunca lo usa, sólo significa que no lo necesitan, y que está muy bien.

La elección de la capa está sujeta a la naturaleza de las especificaciones y el uso. En muchos casos son ayudantes en apoyo de una capa de servicio, pero en algunos casos se encapsulan la lógica de dominio.

En cuanto a la unidad de pruebas, recuerda que sus especificaciones son unidades o contienen unidades. No prueba un método que acepta una especificación con todas las combinaciones posibles de especificación; probar las especificaciones sí mismos para asegurarse de que se comportan como se esperaba, y luego se puede volver a utilizar las mismas especificaciones con confianza en muchos métodos y clases.

La esperanza de que un poco de ayuda.

Answer 2

No creo LINQ es un reemplazo para el patrón de especificación. Recuerde que una especificación es la mejor opción a la lógica de negocio encapsulado. Así que si uno de mis requisitos de negocio tiene conseguirme todos los clientes valorados por varias características mi declaración de LINQ puede tener este aspecto:

var valuedCustomers = Customers.Where(c => c.Orders.Count > 15 && c.Active).ToList();

Puedo escribir cabo esta declaración por toda mi aplicación, pero lo que si quiero agregar a la regla de que el cliente tiene que se han unido antes de una fecha? Pues bien, ahora tengo que ir por todo mi solicitud y cambiar el LINQ. O si mi gráfico de objetos cambia (aunque esto no debe ser la única razón para usar el patrón). Cuando en lugar tan sólo pudiera hacer algo como esto

var valuedCustomers = Customers.Where(new ValuedCustomerRule.IsSatisfied()).ToList();

Estoy de acuerdo que el patrón es más utilizado, pero es muy útil para las reglas de negocio que se presentan a lo largo de su sistema por lo que no es mordido cuando cambian esas reglas. Para mí es similar a las consultas SQL dejando todo el código de aplicación.

Answer 3

Respuesta de Actualización: Estoy de acuerdo con Wix, LINQ no es sustituto de patrón de especificación. No tengo la reputación suficiente para añadir comentarios a la respuesta Wix, sólo estoy respondiendo como respuesta.

Según especificaciones de este papel se utilizan sobre todo para que coincida con un objeto de dominio contra un comunicado. Aunque las especificaciones devuelven verdadero / falso cuando juego contra un objeto de dominio, pero eso especificaciones medias son propuesta para encapsular cualquier condición booleana en el código.

Me va a continuar de la respuesta de Wix más. Si ha definido una especificación ValuedCustomer entonces usted tiene diferente posibilidad de regla de uso:

   var valuedCustomer = new ValuedCustomerSpecification();
   //1. You can use this statement to check if a customer is valued or not in your domain
   Customer customer = ....
   if(valuedCustomer.IsSatisfiedBy(customer))

   //2. You can use it to get just valued customers from repository, 
   var valuedCustomers = repository.Get(valuedCustomer);

   //3. You can combine it with other specifications to create composite specifications. Following syntax can vary with implementation
   var seniorValuedCustomer = valuedCustomer.And(seniorCustomer)

Mi comprensión de papel es que el usuario puede interactuar con las especificaciones para lograr sus objetivos siempre que haya es una necesidad para él y su aplicación para la interfaz de usuario lo permite.

Sobre el papel mencionó también mencionan cuando no a los patrones de uso de la especificación.