Come chiameresti questa classe CRUD?

Question

Cercando di evitare la trappola SomethingManager qui ...

Diciamo che scriverò un editor di utenti che consentirà agli amministratori di creare utenti nel sistema. Funzionalità di base - visualizzare un elenco di utenti esistenti, creare un nuovo utente, aggiornare un utente esistente, eliminare un utente.

Diciamo anche che decido di scrivere una classe "business" per gestire queste operazioni CRUD di base. Questo è probabilmente ciò che l'interfaccia sarà simile:

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

All'interno del metodo SaveUser(), per esempio, vorrei convalidare i dati (utilizzando una classe diversa) e poi effettivamente salvare i dati nel database (usando di nuovo un'altra classe).

La mia domanda è, che cosa dovrei chiamare questa classe? Questa classe sta facendo troppo e quindi dovrei dividerlo in più classi?

Answer 1

Naming è difficile se non è rispettato SRP :) Ma i membri di denominazione viene spesso abusato.

Nel tuo caso farò qualcosa di simile:

• la responsabilità di implementazione è quello di coprire contratto specifico di persistenza
• "chi" è sotto il fuoco

Pensa senza voce - la persistenza è fatta per l'utente e un nome rilevante può essere IUserRepository - i metodi non sono più che per CRUD - perché il IUserRepository è per l'utente, Non è necessario avere UserSave, UserUpdate perché frena l'utilizzo maniera generica

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

E 'difficile? Cosa fare con uno personalizzato?

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

Nel codice utilizzando un contenitore CIO si può fare 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 :)

Answer 2

mia preferenza sarebbe IUserStorage o IUserStore

Answer 3

Perché non solo IUserCRUD? CRUD ha, come indicato per 'gestire' no 10 significati.

Answer 4

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

Answer 5

IUserRepository - come nel modello Repository.

Answer 6

Sto assecondando la chiamata di ChrisW al solo nome "Utente".

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

Answer 7

IUserRepository o IUserServices.

Answer 8

Il fatto che abbiate problemi a nominare questo dovrebbe essere una bandiera rossa gigante che è sbagliato.

Principio di responsabilità singola (e principio di separazione delle interfacce) si applica qui. Spezzalo nelle varie operazioni che ti servono.

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 chiamarli perché ora si applica solo un nome. Fidati di me, se sei un designer, i tuoi sviluppatori ti ameranno per rendere le cose semplici da capire e da usare.

Answer 9

Potrebbe diventare un'interfaccia generica.

ICrud<T> { } 

Oppure ispirato a IUserStore.

IStore<T> { } 

Answer 10

mi piacerebbe andare con UserActions. Questo descrive l'insieme di funzionalità che vuoi fare; evita la trappola di chiamarla collezione (dato che in realtà non raccoglie nulla, semplicemente recupera una collezione).

Ma vorrei anche ripensare a questa classe in questa forma in primo luogo. Sembra che quello che stai cercando di mettere in atto è un gestore di persistenza; ci sono altri tipi di oggetti che vuoi mantenere in questo modo? Puoi estrarre qualsiasi funzionalità comune che possa essere derivata da una classe base? Forse una classe "PersistenceManager" o somesuch? Quindi, se è assolutamente necessario (e non sono sicuro che lo sarebbe), è possibile derivare un "UserPersistenceManager" che funzioni solo sugli oggetti Utente. (Credo che potrebbe non essere necessario perché potresti essere in grado di eseguire tutto ciò che ti serve dallo PersistenceManager, ma solo la tua implementazione specifica può dirlo.)