¿Cómo llamarías a esta clase CRUD?

StackOverflow https://stackoverflow.com/questions/841200

  •  20-08-2019
  •  | 
  •  

Pregunta

Intentando evitar la trampa SomethingManager aquí ...

Digamos que voy a escribir un editor de usuario que permitirá a los administradores crear usuarios en el sistema. Funcionalidad bastante básica: ver una lista de usuarios existentes, crear un nuevo usuario, actualizar un usuario existente, eliminar un usuario.

Digamos también que decido escribir un " business " clase para manejar estas operaciones CRUD básicas. Este es probablemente el aspecto de la interfaz: 

public interface ISomeUsefulName
{
    IList<User> FetchUsers();
    User FetchUser(int userId);
    bool SaveUser(User user);
    bool DeleteUser(int userId);
}

Dentro del método SaveUser (), por ejemplo, validaría los datos (usando una clase diferente) y luego guardaría los datos en la base de datos (nuevamente usando otra clase).

Mi pregunta es, ¿cómo debo llamar a esta clase? ¿Esta clase está haciendo demasiado y, por lo tanto, debería dividirla en varias clases?

¿Fue útil?

Solución

Nombrar es difícil si no se respeta SRP :) Pero los nombres de los miembros a menudo se usan incorrectamente.

En su caso, haré algo como esto:

  • la responsabilidad de la implementación es cubrir el contrato de persistencia especificado
  • `` quién '' está bajo fuego

Piensa sin voz  - la persistencia se realiza para el usuario y un nombre relevante puede ser IUserRepository  - los métodos no son más que para CRUD  - debido al hecho de que IUserRepository es para el usuario, no es necesario tener UserSave, UserUpdate porque frena la forma de uso genérico

La magia está aquí ... solo haz esto: 

public interface IRepository<TYPE, KEY>{
  IList<TYPE> GetAll(KEY key);
  TYPE GetById(KEY key);
  void Save(TYPE obj);
  void Update(TYPE obj);
  void Delete(Key key);
}

¿Es difícil? ¿Qué hacer con uno personalizado? 

public interface IUserRepository : IRepository<User, int>
{
   IList<User> GetAllMyFavorites(ICriteria crit);
   IList<Events> GetHistoryByUser(User user);   
}

En el código que usa un contenedor IoC puede hacerlo fácilmente 

public UserController {
  private _userRepository = null;
  private _eventsRepository = null;

  public UserController(IUserRepository userRepository, 
  IRepository<Events,int> eventsRepository) 
  // if you are doing here just CRUD use the generic signature
  {
    _userRepository = userRepository;
    _eventsRepository = eventsRepository;
  }

  public MarkItAsGoldPartener(int userId){
     var user = userRepository.GetById(userId);
     user.PartnerType = PartnerTypes.Gold;
     userRepository.Save(user); // the user in member name is useless
     eventsRepository.Save(new Event(){Message = "The user" + UserId + "is golden" });
  }
}

buena suerte :)

Otros consejos

Estoy secundando la llamada de ChrisW para nombrarlo simplemente "Usuario".

Cada vez que se encuentre colocando la misma cadena en el nombre de casi todos los métodos, debe eliminarse de los nombres de los métodos y colocarse en el nombre de la clase.

IUserRepository - como en el Repository .

Mi preferencia sería IUserStorage o IUserStore

IUserRepository o IUserServices.

El hecho de que tenga problemas para nombrar esto debería ser una señal de alerta gigante de que está mal.

El principio de responsabilidad única (y el principio de segregación de interfaz) se aplica aquí. Divídalo en las diversas operaciones que necesita. 

public interface IUserList
{
    IList<User> FetchUsers();
}

public interface IUser
{
   User FetchUser(int userId);
}

public interface IUserStore
{
    bool SaveUser(User user);
    bool DeleteUser(int userId);
}

y luego se vuelve mucho más simple nombrarlos porque ahora solo se aplica un nombre. Confía en mí, si eres un diseñador, tus desarrolladores te amarán por hacer que las cosas sean simples de entender y usar.

Podría convertirse en una interfaz genérica. 

ICrud<T> { }

O inspirado por IUserStore. 

IStore<T> { }

¿Por qué no solo el usuario CRUD? CRUD no tiene, en lugar de "gestionar", ningún significado.

¿Qué hay de llamarlo " Usuarios " (o "Usuarios autorizados" o "Colección de usuarios")?

Me gustaría ir con UserActions . Esto describe el conjunto de funcionalidades que desea hacer; evita la trampa de llamarlo una colección (ya que en realidad no recopila nada, simplemente recupera una colección).

Pero también volvería a pensar en tener esta clase en esta forma en primer lugar. Parece que lo que estás tratando de poner en marcha es un administrador de persistencia; ¿Hay algún otro tipo de objeto que quiera persistir de esta manera? ¿Se puede extraer alguna funcionalidad común que luego se pueda derivar a una clase base? Quizás un " PersistenceManager " clase o somesuch? Entonces, si es absolutamente necesario (y no estoy seguro de que lo sea), podría derivar un " UserPersistenceManager " eso funcionaría solo en objetos de usuario. (Creo que puede no ser necesario porque puede realizar todo lo que necesita solo desde el PersistenceManager ; sin embargo, solo su implementación específica puede decirle eso).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top