¿Cómo clasificaría este tipo de diseño para las clases?

Question

El siguiente tipo de diseño que he visto tiene básicamente clases "delgadas", excluyendo cualquier tipo de comportamiento. Una clase secundaria se usa para insertar/actualizar/eliminar/obtener.

¿Esto está mal? ¿Es anti OOP?

User.cs 

public class User 
{ 

    public string Username { get; set; } 
    public string Password { get; set; } 
} 


Users.cs 


public class Users 
{ 
    public static User LoadUser(int userID) 
    { 
      DBProvider db = new DBProvider(); 
      return dp.LoadUser(userID); 

     } 

} 

Answer 1

Lo clasificaría como un objeto de dominio u objeto comercial. Una de las ventajas de este tipo de diseño es que mantiene el modelo independiente de cualquier lógica comercial y pueden reutilizarse en diferentes tipos de entornos.

La segunda clase podría clasificarse como DAO (Objeto de acceso a datos).

Este patrón no es anti-oop en absoluto y es ampliamente utilizado.

Answer 2

Creo que está implementando un domain model y un data-access object. Es una buena idea.

Answer 3

Mientras que su clase user.cs se presta para un domain transfer object, la clase Users.cs es esencialmente donde puede aplicar reglas de negocio dentro del data-access objects.

Es posible que desee pensar en la convención de nomenclatura de sus clases junto con los espacios de nombres. Cuando miro un users.cs, supongo que será esencialmente una clase para trabajar con una lista de usuarios.

Otra opción sería buscar en el Active Record Pattern, que combinaría las dos clases que ha creado.

User.cs 

public class User 
{ 
    public string Username { get; set; } 
    public string Password { get; set; } 

    public User(int userID) 
    { 
     //data connection 
     //get records 
     this.Username = datarecord["username"]; 
     this.Password = datarecord["password"]; 
    } 
} 

Answer 4

Parece que podría ser el repository pattern esto parece ser un patrón cada vez más común y se utiliza para gran efecto en Rob Conery's Storefront ejemplo Asp.Net MVC aplicación.

Básicamente está abstrayendo su código de acceso a datos del Modelo, lo cual es bueno, en general. Aunque espero un poco de agallas para la clase modelo. También por experiencia previa, llamarlo Usuarios es confuso, UserRepository podría ser mejor. También es posible que desee considerar la eliminación de estática (que es un debate candente), pero hace que la burla sea más fácil. Además, el repositorio debería implementar una interfaz para que puedas simularlo y, por lo tanto, reemplazarlo por un falso más tarde.

Answer 5

No está realmente orientado a objetos en ningún sentido, ya que el objeto no es más que un conjunto de datos pegados entre sí. No es que sea algo terrible.

Answer 6

La primera clase es anti-OOP porque contiene datos sin comportamiento, un ejemplo típico de anemic domain model. Es típico para las personas que hacen programación de procedimientos en un lenguaje OO.

Sin embargo, las opiniones se basan en si tiene sentido poner lógica de acceso DB en el propio modelo de dominio (patrón de registro activo) o, como en su código, en una clase separada (patrón de Objeto de acceso a datos), desde acceso DB es una preocupación técnica separada que no necesariamente debe estar estrechamente relacionada con el modelo de dominio.