Comment nommeriez-vous cette classe CRUD?

Question

Essayez d'éviter le piège SomethingManager ici ...

Disons que je vais écrire un éditeur d’utilisateur qui permettra aux administrateurs de créer des utilisateurs dans le système. Fonctionnalité assez basique: affichez la liste des utilisateurs existants, créez un nouvel utilisateur, mettez à jour un utilisateur existant, supprimez un utilisateur.

Disons également que je décide d’écrire une "entreprise". classe pour gérer ces opérations de base CRUD. C’est probablement à quoi ressemblerait l’interface:

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

Dans la méthode SaveUser (), par exemple, je validerais les données (en utilisant une classe différente), puis les enregistrerais dans la base de données (en utilisant à nouveau une autre classe).

Ma question est la suivante: comment nommer cette classe? Cette classe en fait-elle trop et par conséquent je devrais la diviser en plusieurs classes?

Answer 1

Nommer est difficile s'il n'est pas respecté SRP :) Mais les noms des membres sont souvent mal utilisés.

Dans votre cas, je vais faire quelque chose comme ceci:

• la responsabilité de la mise en œuvre est de couvrir un contrat de persistance spécifié
• " qui " est sous le feu

Pense sans voix  - la persistance est faite pour l'utilisateur et un nom pertinent peut être IUserRepository  - les méthodes ne sont pas plus que pour CRUD  - en raison du fait que IUserRepository est destiné à l'utilisateur, il n'est pas nécessaire d'avoir UserSave, UserUpdate, car cela freine l'utilisation générique

La magie est là ... faites ceci:

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);
}

Est-ce difficile? Que faire avec un personnalisé?

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

Dans le code utilisant un conteneur IoC, vous pouvez le faire facilement

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" });
  }
} 

bonne chance:)

Answer 2

J'appuie l'appel de ChrisW pour le nommer simplement "utilisateur".

Chaque fois que vous mettez la même chaîne dans le nom de presque toutes les méthodes, vous devez la supprimer des noms de méthodes et la placer dans le nom de la classe.

Answer 3

IUserRepository - comme dans le modèle Référentiel .

Answer 4

Mes préférences seraient IUserStorage ou IUserStore

Answer 5

IUserRepository ou IUserServices.

Answer 6

Le fait que vous rencontriez des difficultés pour le nommer devrait être un drapeau rouge géant indiquant que c'est faux.

Le principe de responsabilité unique (et le principe de séparation des interfaces) s'appliquent ici. Découpez-le en différentes opérations dont vous avez besoin.

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

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

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

et puis il devient beaucoup plus simple de les nommer car maintenant un seul nom s’applique vraiment. Croyez-moi, si vous êtes un designer, vos développeurs vous aimeront pour rendre les choses simples à comprendre et à utiliser.

Answer 7

Cela pourrait devenir une interface générique.

ICrud<T> { }

Ou inspiré par IUserStore.

IStore<T> { }

Answer 8

Pourquoi ne pas simplement utiliser CRUD? CRUD a, par opposition à «gérer» pas 10 significations.

Answer 9

Pourquoi ne pas l'appeler " Utilisateurs " (ou "AuthorizedUsers" ou "CollectionOfUsers")?

Answer 10

Je choisirais UserActions . Ceci décrit le jeu de fonctionnalités que vous voulez faire. cela évite le piège de l’appeler une collection (puisqu’elle ne collectionne rien, elle récupère simplement une collection).

Mais je penserais aussi que cette classe soit sous cette forme en premier lieu. On dirait que ce que vous essayez de mettre en place est un gestionnaire de persistance; Y a-t-il d'autres types d'objets que vous allez vouloir conserver de cette manière? Pouvez-vous extraire une fonctionnalité commune pouvant ensuite être dérivée dans une classe de base? Peut-être un " PersistenceManager " classe ou quelque chose? Ensuite, si cela est absolument nécessaire (et je ne suis pas certain que ce le serait), vous pouvez obtenir un " UserPersistenceManager ". cela ne fonctionnerait que sur les objets utilisateur. (Je pense que cela n’est peut-être pas nécessaire, car vous pourrez peut-être exécuter tout ce dont vous avez besoin uniquement à partir de PersistenceManager ; seule votre implémentation spécifique peut vous dire cela.)