¿Cómo definirías esta clase de CRUD?

Question

Tratando de evitar la trampa de 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 una clase de "negocios" para manejar estas operaciones CRUD básicas. Esto es probablemente lo que la interfaz se vería así:

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, yo sería la confirmación de los datos (usando una clase diferente) y luego en realidad guardar los datos en la base de datos (utilizando de nuevo otra clase).

Mi pregunta es, ¿qué nombre debo dar a esta clase? ¿Esta clase está haciendo demasiado y por lo tanto debería dividirla en múltiples clases?

Answer 1

de nombres es difícil, si no se respeta SRP :) embargo, los miembros de nomenclatura es a menudo mal.

En su caso voy a hacer algo como esto:

• la responsabilidad de la aplicación es para cubrir contrato especificado de la persistencia
• "que" está bajo el 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 el manner uso genérico

La magia está aquí ... simplemente hacer 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 mediante un contenedor IoC usted puede hacer 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 :)

Answer 2

Mi preferencia sería IUserStorage o IUserStore

Answer 3

¿Por qué no IUserCRUD? CRUD tiene, como oposición a 'gestionar' no hay 10 significados.

Answer 4

¿Qué le parece llamarlo "Usuarios" (o "Usuarios autorizados" o "Miembros de la colección")?

Answer 5

IUserRepository - como en el patrón Repository.

Answer 6

Estoy secundando la llamada de ChrisW simplemente con el nombre "Usuario".

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

Answer 7

IUserRepository o IUserServices.

Answer 8

El hecho de que tenga problemas para nombrar esto debería ser una bandera roja gigante que indica que está mal.

Principio de Responsabilidad Individual (y Principio de Segregación de Interfaz) se aplica aquí. Divide en las diversas operaciones que necesitas.

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. Créeme, si eres un diseñador, tus desarrolladores te adorarán por hacer que las cosas sean fáciles de entender y usar.

Answer 9

Podría convertirse en una interfaz genérica.

ICrud<T> { } 

O inspirado en IUserStore.

IStore<T> { } 

Answer 10

me gustaría ir con UserActions. Esto describe el conjunto de funcionalidades que desea hacer; evita la trampa de llamarlo una colección (dado 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 implementar es un administrador de persistencia; ¿Hay algún otro tipo de objetos que quieras persistir de esta manera? ¿Puedes extraer alguna funcionalidad común que luego pueda derivarse a una clase base? Tal vez una clase "PersistenceManager" o somesuch? Entonces, si es absolutamente necesario (y no estoy seguro de que lo sea), podría derivar un "UserPersistenceManager" que funcionaría solo en los objetos del Usuario. (Creo que puede que no sea necesario porque puede realizar todo lo que necesita desde el PersistenceManager; sin embargo, solo su implementación específica puede indicarlo)