Domanda

Cercando di evitare la SomethingManager qui ...

Diciamo che scriverò un editor utente che consentirà agli amministratori di creare utenti nel sistema. Funzionalità piuttosto basilari: visualizza un elenco di utenti esistenti, crea un nuovo utente, aggiorna un utente esistente, elimina un utente.

Diciamo anche che decido di scrivere un " business " classe per gestire queste operazioni CRUD di base. Questo è probabilmente l'aspetto dell'interfaccia:

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

All'interno del metodo SaveUser (), ad esempio, vorrei convalidare i dati (usando una classe diversa) e quindi effettivamente salvare i dati nel database (usando ancora un'altra classe).

La mia domanda è: come dovrei nominare questa classe? Questa classe sta facendo troppo e quindi dovrei dividerla in più classi?

È stato utile?

Soluzione

La denominazione è difficile se non viene rispettato SRP :) Ma la denominazione dei membri viene spesso utilizzata in modo improprio.

Nel tuo caso, farò qualcosa del genere:

  • la responsabilità dell'attuazione è quella di coprire il contratto di persistenza specificato
  • " che " è sotto tiro

Pensa senza voce  - la persistenza viene eseguita per l'utente e un nome rilevante può essere IUserRepository  - i metodi non sono più che per CRUD  - a causa del fatto che IUserRepository è per l'utente, non è necessario disporre di UserSave, UserUpdate perché frena la modalità di utilizzo generico

La magia è qui ... basta fare questo:

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

È difficile? Cosa fare con uno personalizzato?

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

Nel codice usando un contenitore IoC puoi farlo facilmente

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

buona fortuna :)

Altri suggerimenti

Sto facendo appello alla chiamata di ChrisW per chiamarla semplicemente " Utente " ;.

Ogni volta che ti trovi a inserire la stessa stringa nel nome di quasi tutti i metodi, dovrebbe essere rimosso dai nomi dei metodi e inserito nel nome della classe.

IUserRepository - come nel modello Repository .

La mia preferenza sarebbe IUserStorage o IUserStore

IUserRepository o IUserServices.

Il fatto che tu abbia problemi a nominare questo dovrebbe essere una gigantesca bandiera rossa che è sbagliato.

Il principio di responsabilità singola (e il principio di segregazione dell'interfaccia) si applica qui. Suddividilo nelle varie operazioni di cui hai bisogno.

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

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

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

e quindi diventa molto più semplice nominarli perché ora si applica solo un nome. Fidati di me, se sei un designer i tuoi sviluppatori ti adoreranno per rendere le cose semplici da capire e usare.

Potrebbe diventare un'interfaccia generica.

ICrud<T> { }

O ispirato a IUserStore.

IStore<T> { }

Perché non solo User CRUD? CRUD ha, al contrario di "gestire" no 10 significati.

Che ne dici di chiamarlo " Utenti " (o " Utenti autorizzati " o " CollectionOfUsers ")?

Andrei con UserActions . Descrive l'insieme di funzionalità che si desidera eseguire; evita la trappola di chiamarla collezione (dal momento che in realtà non raccoglie nulla, recupera semplicemente una raccolta).

Ma ripenserei anche all'inizio di questa classe in questo modulo. Sembra che ciò che stai cercando di mettere in atto sia un gestore di persistenza; ci sono altri tipi di oggetti che vorresti persistere in questo modo? È possibile estrarre funzionalità comuni che possono quindi essere derivate in una classe base? Forse un " PersistenceManager " classe o qualcosa del genere? Quindi, se è assolutamente necessario (e non sono sicuro che lo sarebbe), potresti derivare un " UserPersistenceManager " che opererebbe solo sugli oggetti Utente. (Credo che potrebbe non essere necessario perché potresti essere in grado di eseguire tutto ciò di cui hai bisogno solo dal PersistenceManager ; tuttavia solo la tua implementazione specifica può dirti che.)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top