Aquí podría ser tu PUBLICIDAD


Mejores prácticas para Active Record Pattern y uso de métodos estáticos para operaciones grupales

votos
0

Es cierto lo que dicen sobre los patrones de diseño que son simplemente la encarnación de técnicas que ya son de uso general. He estado usando el patrón de registro activo desde 1985.

Uno de los atributos de este patrón es el uso de miembros estáticos en la implementación para realizar búsquedas que devuelvan colecciones de los datos subyacentes.

class Customer { 
   static Customer FindCustomerById( int Id ) { ... } 
   static Customer[] FindActiveCustomers() { ... }
}

En muchos casos en los que necesito mucha más flexibilidad, rompo la encapsulación e incluyo un método como

static Customer[] FindCustomers( string criteria ) { ... } 

donde uno lo llamaría como

Customer[] customers = Customer.FindCustomers( LastName = 'Smith' );

Por supuesto, esto es una retención de cuando usé este patrón en C, claramente no es una mejor práctica, y en las manos equivocadas puede llevar a la inyección de SQL y otros problemas.

¿Existe un patrón o práctica adecuada que pueda aplicarse que permita que la clase del Cliente se convierta en un criterio para dicha búsqueda?

Por ejemplo, supongamos que quiero encontrar clientes cuyo apellido era Smith, podría considerar escribir una implementación como:

static Customer[] FindCustomers( Customer customer ) { ... }

ser llamado como (con el constructor apropiado por supuesto):

Customer[] customersnamedsmith = 
   Customer.FindCustomer( new Customer( Smith ) );

¿O es mejor crear una clase conjunta que defina los criterios?

Publicado el 12/03/2009 a las 19:10
fuente por usuario Bill
En otros idiomas...        العربية       

4 respuestas

votos
1

Solo por trabajar con LINQ, me gusta la idea de pasar una expresión en lugar de una cadena. Pero, tal vez ese es solo yo? Tampoco soy aficionado a ActiveRecord, ya que mezcla estado y comportamiento en el mismo objeto. Buen empaque, pero no una separación clara entre el modelo y el acceso a los datos.

He visto casos en los que se pasa una clase de cliente a registro activo, pero si va por esa ruta, un patrón de depósito es mucho más limpio y separa el comportamiento del estado. Sin embargo, no veo nada de malo en utilizar la inversión que ya tiene en el registro activo y pasar un objeto.

Si desea crear una clase de criterios, terminará con un patrón de estrategia poco, lo que puede hacer que su registro activo sea un poco más activo de lo que es hoy. Sin embargo, es un patrón aplicable y también resolverá cualquier problema de inyección.

Respondida el 12/03/2009 a las 07:17
fuente por usuario Gregory A Beamer


Aquí podría ser tu PUBLICIDAD


votos
0

Echar un vistazo a la muestra WWPlatform DataAccess en CodePlex. Se muestra un ejemplo excelente de proporcionar instancias de especificación de búsqueda como params aunque a través del patrón de repositorio.

Respondida el 12/08/2010 a las 05:30
fuente por usuario Darren Lewis

votos
0

Sin una razón para no hacerlo, proporcionaría un método como este:

public static IEnumerable<Customer> AllCustomers()
{
   return Customers.AsEnumerable();
}

Si tiene razones para no hacer esto, necesita articular esos motivos y examinarlos en detalle para diseñar la solución correcta.

Respondida el 12/03/2009 a las 08:48
fuente por usuario Robert Rossney

votos
0

A pesar de que lo saca del nivel de la base de datos, puede usar algo similar a un comparador. No sé C #, así que simplemente lo hice, pero entiendes lo esencial:

class CustomerLastNameEvaluator : IEvaluate
{
    private Customer _customer;

    public CustomerLastNameEvaluator (String lastName)
    {
        _customer = new Customer (lastName);
    }

    bool IEvaluate.Evaluate(Customer c)
    {
        return (_customer.LastName == c.LastName);
    }
}

Customer[] customers = Customer.FindCustomers( new CustomerLastNameEvaluator("Smith") );
Respondida el 12/03/2009 a las 07:27
fuente por usuario Pesto