C# классы и методы

Question

Мне сложно определить ответственность классов: мне нужно поместить этот метод в этот класс или я должен поместить этот метод в другой класс? Например, представьте простой класс пользователя с идентификатором, именем, фамилией и паролем. Теперь у вас есть userId, и вы хотите имя forname и lastname, поэтому вы создаете такой метод, как: public User GetUserById (int id) {}. Затем вы хотите показать список всех пользователей, поэтому вы создаете другой метод: public List GetAllUsers() {}. И, наконец, вы хотите обновить, удалить и сохранить пользователя. Это дает нам 5 методов:

public bool SaveUser(User user); 
public bool UpdateUser(User user); 
public bool DeleteUser(User user); 
public User GetUserById(int id); 
public List<User> GetAllUsers(); 

Итак, мой вопрос: вы ставите все эти методы в классе User? Или вы создаете еще один класс данных (класс UserData), который может подключаться к базе данных и содержать все эти методы?

Answer 1

Что вы здесь описываете, это в основном выбор между Active Record Pattern или Repository Pattern. Я бы посоветовал вам прочитать эти шаблоны и выбрать то, что подходит вашему приложению/опыту/набору инструментов.

Answer 2

При прочих равных условиях в любом случае это нормально. Выбор, однако, обычно зависит от общей архитектуры приложения или библиотеки классов, в которой вы найдете класс User. Если код доступа к данным кажется запутанным с объектным кодом User, тогда может возникнуть смысл разделить его на два класса, как вы считали. Если методы CRUD являются однострочными делегациями в DAL с, возможно, специфичной для приложения логикой, то оставлять их в классе User должно быть в порядке.

Сложность более или менее одинакова в обоих случаях - это компромисс между сборкой с низким уровнем maintenace с несколькими классами с высоким уровнем обслуживания или высокопроизводительной сборкой с большим количеством классов с низким уровнем обслуживания.

Я также предполагаю, что методы CRUD должны быть static.

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

Answer 3

Я бы не поместил эти конкретные методы в класс «Пользователь».

Есть 2 общих подходы к этим «проблемам»:

• Вы помещаете эту методу в классе User , и тогда это означает, что вы «повторно с помощью Active Record шаблона
• Вы помещаете эти методы в отдельном классе (UserRepository) для экземпляра , а затем вы используете шаблон Repository.

Я предпочитаю подход к репозиторию, так как он сохраняет мой класс «Пользователь» чистым и не загромождает его кодом доступа к данным.

Answer 4

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

Answer 5

Эти методы звучат скорее как UserManager (или что-то в этом роде) для меня. Класс пользователя должен соответствовать и представлять только пользователя, не так много.

Answer 6

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

Answer 7

Если мы рассмотрим шаблоны проектирования Enterprise Application, то методы для извлечения пользователей, то есть GetUserByID и GetAllUsers, будут в отдельном классе - вы можете назвать его UserData или UserDAO (DAO - Data Access Object).

Infact вы должны разработать интерфейс для UserDAO с соответствующими методами обработки пользовательских объектов - таких как CreateUser, UpdateUser, DeleterUser, GetUserXXX и т. Д.

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

Ниже приведен преимущества поддержания методов доступа в отдельном классе:

1) объект пользователя должен быть простым объектом с сеттерами только геттерными, это облегчило бы прохождение объекта по уровням - от уровня доступа к данным, к делу от уровня к веб-уровню. Это также помогло бы сохранить пользовательский объект serializable

2) Логика доступа к данным слабо связана с объектом User - это означает, что если источник данных изменяется, то вам не нужно изменять сам объект User. Это также помогает в тестировании разработки, где вам могут потребоваться фальшивые объекты во время фазы тестирования

3) Если объект пользователя является сложным объектом с отношениями с другими объектами, такими как адрес или отдел или роль и т. Д., Тогда сложность отношений будет быть инкапсулирован в UserDAO, а не протекать в пользовательском объекте.

4) Портирование в рамках как NHibernate или Spring.NET или .NET LINQ станет легче, если шаблоны следуют

Answer 8

Давайте посмотрим, вам сценарий, как это.

Количество людей, участвующих в собрании, состоит из N.

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

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

Поэтому у вас есть два объекта

1) Пользователь/лицо, работающее в вашей сборке deivision 2) Менеджер

Таким образом, два класса. Надеюсь, это поможет вам.

Благодаря