Блог

Извините, если заголовок сформулирован не лучшим образом.

В моем пользовательском хранилище есть метод, который создаст нового пользователя. Куда следует направить мою проверку, чтобы убедиться, что заполнены все поля, необходимые для создания пользователя: имя пользователя, пароль, электронная почта и Создано. Если какое-либо из значений равно null, то вставка выдаст ошибку.

 public class UserRepository : IRepository<User>
{
    public DbConnection Connection { get; set; }

    public UserRepository(DbConnection connection)
    {
        this.Connection = connection;
    }

    public void Create(User user)
    {
        string sql = "INSERT INTO [dbo].[User] (Username, Password, Email, Created) VALUES (@Username, @Password, @Email, @Created)";

        using (DbCommand command = new SqlCommand())
        {
            command.Connection = this.Connection;
            command.CommandText = sql;
            command.Parameters.Add(new SqlParameter("@Username", user.Username));
            command.Parameters.Add(new SqlParameter("@Password", user.Password));
            command.Parameters.Add(new SqlParameter("@Email", user.Email));
            command.Parameters.Add(new SqlParameter("@Created", user.Created));
            command.ExecuteScalar();
        }
    }        
}
  

Должен ли мой метод create действительно проверять значения здесь? Я чувствую, что здесь не следует выполнять проверку, но я не уверен, что это подходящее место для разделения.

Всегда полезно отделять бизнес-логику от кода доступа к данным. Это делает код бизнес-логики более читаемым и поддерживаемым. «Проверка» здесь является частью бизнес-логики, поэтому я рекомендую обрабатывать ее на верхнем уровне. Подумайте о создании «сервисных» классов, которые получают входные данные, проверяют их и осуществляют доступ к БД через репозиторий.

Допустим, ваш сценарий — «создать нового пользователя путем регистрации». Имеет смысл иметь RegistrationService класс с CreateUser методом.

Существует другой вариант использования User самого класса для проверки. Вы можете сделать пользовательский класс неизменяемым, заставить его получать все параметры в конструкторе и проверять их во время построения. Таким образом, вы исключаете возможность наличия «недопустимого» экземпляра. Любая функция, которая получает User в качестве параметра, на самом деле гарантированно получит экземпляр «действительного пользователя».

В качестве последнего замечания, это помогает выработать привычку проверять наличие нулевых аргументов и вставлять ArgumentNullException в public функции, независимо от проверки.

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

Для меня Create функция — это та, которая определяет это. Какая информация вам требуется для создания пользователя из User экземпляра?

Я бы проверил это прямо там.