2009-05-08 9 views
6

Пытается избежать ловушки SomethingManager здесьЧто бы вы назвали этим классом CRUD?

Предположим, что я напишу редактор пользователя, который позволит администраторам создавать пользователей в системе. Довольно основные функции - просмотр списка существующих пользователей, создание нового пользователя, обновление существующего пользователя, удаление пользователя.

Давайте также скажем, что я решил написать класс «бизнес» для обработки этих основных операций CRUD. Это, вероятно, что интерфейс будет выглядеть следующим образом:

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

Внутри метода SaveUser(), к примеру, я бы проверить данные (с помощью другого класса), а затем фактически сохранить данные в базу данных (снова используя другой класс).

Мой вопрос: как назвать этот класс? Является ли этот класс слишком много, и поэтому я должен разбить его на несколько классов?

ответ

6

Нейминг трудно, если не соблюдается SRP :) Но члены именование часто неправильно.

В вашем случае я буду делать что-то вроде этого:

  • ответственность осуществления является покрытие указанного договора упорства
  • «который» находится под огнем

Думает без голоса - постоянство выполняется для пользователя, а релевантное имя может быть IUserRepository - методы не более чем для CRUD - из-за того, что IUserRepository для пользователя, не нужно иметь UserSave, UserUpdate, потому что она тормозит родовую манеру использования

The Magic здесь ... просто это сделать:

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

Является ли это сложно? Что делать с обычным?

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

В коде, используя контейнер IoC вы можете легко сделать

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

удачи :)

+0

+1 Хороший ответ. Вы подумали об этом лучше, чем я. –

2

Мое предпочтение было бы IUserStorage или IUserStore

+0

+1 для IUserStore –

1

Почему просто не IUserCRUD? CRUD имеет, как и «управляет» значением не 10.

+0

... и, конечно, crud "не имеет других нереальных значений. ;-) –

1

Как насчет того, чтобы называть его «Пользователи» (или «Авторизованные пользователи» или «КоллекцияОфюзеры»)?

+0

Это мой голос. –

3

IUserRepository - как в модели Repository.

+0

http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx еще одна ссылка, помогающая очистить ее. – scottm

5

Я почитаю вызов ChrisW, чтобы назвать его «Пользователь».

Каждый раз, когда вы обнаруживаете, что вы вставляете одну и ту же строку в имя почти каждого метода, ее следует удалить из имен методов и поместить в имя класса.

+0

+1, чтобы затем удалить существительное (т. Е. Имя класса) из имени метода. – ChrisW

+0

У него уже есть класс пользователя; если вы не предполагаете, что он перенесет эту функциональность в класс User (не обязательно плохая идея), не будет ли это немного ... «collision-y»? :-) –

+0

@McWafflestix: Тогда это может быть «UserManagement» или «UserIO». Просто удалите это имя из методов и в класс, где он принадлежит. –

2

Тот факт, что у вас возникли проблемы с этим, должен быть гигантский красный флаг, который является неправильным.

Здесь применим принцип единой ответственности (и принцип разделения интерфейса). Разбейте его на различные операции, которые вам нужны.

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

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

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

, а затем становится намного проще назвать их, потому что теперь применяется только одно имя. Поверьте мне, если вы дизайнер, ваши разработчики будут любить вас, чтобы сделать вещи простыми для понимания и использования.

+0

Я думаю, что IUser - плохой выбор - я бы рассмотрел класс User для реализации IUser. То же самое с IUserList. Но IUserStore неплох, но он должен содержать все четыре метода. –

2

Это может стать универсальным интерфейсом.

ICrud<T> { } 

Или вдохновлен IUserStore.

IStore<T> { } 
0

Я бы пойти с UserActions. Это описывает набор функций, которые вы хотите сделать; он избегает ловушки вызова его коллекции (поскольку он фактически ничего не собирает, просто извлекает коллекцию).

Но я также переосмыслил бы этот класс в этой форме в первую очередь. Похоже, что вы пытаетесь создать на месте менеджер по сохранению; существуют ли какие-либо другие типы объектов, которые вы захотите сохранить таким образом? Можете ли вы извлечь какую-либо общую функциональность, которая затем может быть выведена на базовый класс? Возможно, класс «PersistenceManager» или что-то подобное? Тогда, если это абсолютно необходимо (и я не уверен, что это будет), вы можете получить «UserPersistenceManager», который будет работать только с объектами пользователя. (Я считаю, что это может быть необязательно, потому что вы можете выполнять все, что вам нужно, только с PersistenceManager, но только ваша конкретная реализация может сказать вам об этом.)