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

Question

Мне трудно определить ответственность классов: должен ли я поместить этот метод в этот класс или мне следует поместить этот метод в другой класс? Например, представьте простой пользовательский класс с идентификатором, именем, фамилией и паролем. Теперь у вас есть userId и вам нужны имя и фамилия, поэтому вы создаете метод, такой как: 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

То, что вы здесь описываете, это в основном выбор между шаблоном активной записи или шаблоном репозитория . Я бы посоветовал вам ознакомиться с этими шаблонами и выбрать тот, который подходит вашему приложению / опыту / набору инструментов.

Answer 2

Я бы не помещал эти конкретные методы в класс 'User'.

Существует 2 общих подхода к этой «проблеме»:

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

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

Answer 3

Позволяет нам увидеть ваш сценарий следующим образом.

В отделе сборки вашей компании работает N сотрудников.

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

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

Поэтому у вас есть две сущности

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

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

Спасибо

Answer 4

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

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

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

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

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

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

3) Если объект «Пользователь» является сложным объектом с отношениями с другими объектами, такими как «Адрес», «Отдел», «Роль» и т. Д., То сложность отношений будет заключена в UserDAO, а не в утечку в объекте «Пользователь».

4) Портирование на фреймворки, такие как NHibernate или Spring.NET или .NET LINQ, станет проще, если следовать шаблонам

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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

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