Как я могу прервать инициализацию объекта?

Question

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

public class User 
{ 
    public string Name { get; set; } 

    public User(string name) 
    { 
     Name = name; 
    } 
} 

Теперь есть несколько бизнес-правил, которые мне необходимо реализовать в этом классе. Одним из них является то, что свойство Name должно быть уникальным именем. Так что, я думаю, что инициализатор для этого объекта будет выглядеть это:

public User(string name, IQueryable<User> allUsers) 
    { 
     var matches = allUsers.Where(q => q.Name == name).ToList(); 
     if(matches.Any()) 
     { 
      // abort object initialization 
     } 
     Name = name; 
    } 

Но я не знаю, как я бы прервать процесс инициализации объекта. На самом деле это возможно?

Есть ли способ прервать инициализацию объекта (то есть: установить объект в null) или есть лучший способ выполнить это?

Answer 1

Отмена инициализации объекта выполняется путем исключения исключения в конструкторе и рекомендуется отклонять недопустимый ввод.

public class User 
{ 
    public User(String name) { 
     if (String.IsNullOrWhiteSpace(name)) { 
      if (name == null) { 
       throw new System.ArgumentNullException("Cannot be null.", "name"); 
      } 
      else { 
       throw new System.ArgumentException("Cannot be empty.", "name"); 
      } 
     } 
    } 
} 

Бизнес-логика, которую вы хотите определить в конструкторе, не подходит. Конструкторы должны быть легкими и создавать только экземпляр. Запрос на некоторый источник данных слишком дорого для конструктора. Из-за этого вы должны использовать шаблон фабрики вместо этого. С заводским шаблоном, вызывающий может ожидать, что будет некоторый тяжелый подъем, связанный с созданием объекта.

public class User 
{ 
    private User(String name) { 
     if (String.IsNullOrWhiteSpace(name)) { 
      if (name == null) { 
       throw new System.ArgumentNullException("Cannot be null.", "name"); 
      } 
      else { 
       throw new System.ArgumentException("Cannot be empty.", "name"); 
      } 
     } 
    } 

    public static User CreateUser(String name) { 
     User user = new User(name); // Lightweight instantiation, basic validation 

     var matches = allUsers.Where(q => q.Name == name).ToList(); 

     if(matches.Any())   
     {   
      throw new System.ArgumentException("User with the specified name already exists.", "name");   
     }  

     Name = name; 
    } 

    public String Name { 
     get; 
     private set; // Optionally public if needed 
    } 
} 

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

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

public class User 
{ 
    public User(String name) { 
     if (String.IsNullOrWhiteSpace(name)) { 
      if (name == null) { 
       throw new System.ArgumentNullException("Cannot be null.", "name"); 
      } 
      else { 
       throw new System.ArgumentException("Cannot be empty.", "name"); 
      } 
     } 
    } 
} 

public class SomeDataSource { 
    public void AddUser(User user) { 
     // Do your business validation here, and either throw or possibly return a value 
     // If business rules pass, then add the user 
     Users.Add(user); 
    } 
} 

Answer 2

Я полагаю, вы можете проверить и выбросить исключение в конструкторе объекта или в установщике имен, но eeeehhhh, который может содержать множество проблем и смешанных проблем. Я говорю создать объект через фабрику, которая выполняет эту проверку, и возвращает значение null (или красиво названное исключение). Или создайте объект POCO и выполните проверку с помощью отдельного класса/метода.

Answer 3

Прежде чем создавать пользователя, вам следует проверить дублирующее имя.

Answer 4

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

Answer 5

Лично я запускаю логические проверки до того, как я создаю экземпляр. Например:

if(UserLogic.PreInsertValidation(string username)){ 
    User newUser = new User(username); 
} 
else{ 
    // Handling - maybe show message on client "The username is already in use." 
} 

PreInsertValidation бы все бизнес-логики проверки, основанные на ваших требованиях.

Answer 6

Что вы ищете, это шаблон identity map, или что-то в этом роде. Вероятно, неправильно оставить эту ответственность в самом объекте, это должно быть сделано в компоненте, создающем сущности. конечно, карта shoul может быть потокобезопасной, если это необходимо, во избежание условий гонки.

Answer 7

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

Answer 8

Вместо того, чтобы иметь открытый конструктор, есть метод, как это и частный конструктор:

public static User CreateUser(string name) 
{ 
     // Check whether user already exists, if so, throw exception/return null 

     // If name didn't exist, record that this user name is now taken. 
     // Construct and return the user object 
     return new User(name); 
} 

private User(string name) 
{ 
     this.Name = name; 
} 

Затем ваш вызывающий код может использовать User myUser = User.CreateUser("Steve"); и обрабатывать нулевой обратный/исключение соответственно.

Следует добавить, что любой метод, который вы используете, который хранит имена пользователей, должен быть обновлен, чтобы сказать, что это имя принято в методе CreateUser. В противном случае, если вы подождите некоторое время, прежде чем хранить этот объект в базе данных или что-то еще, у вас все еще будут проблемы. Я обновил код выше, чтобы сделать это более понятным.

Answer 9

Вместо того, чтобы выполнять эту проверку внутри самого объекта, поместите создание, проверку и сохранение этого объекта в службе. Эта служба может вызывать ValidationException, когда имя пользователя не является уникальным, и даже может начать транзакцию, чтобы гарантировать, что никакое состояние гонки не может произойти. Хорошей моделью, которую я использую, является модель command/handler. Вот пример:

public class CreateNewUserCommand 
{ 
    public string UserName { get; set; } 
} 

internal class CreateNewUserCommandHandler 
    : ICommandHandler<CreateNewUserCommand> 
{ 
    private readonly IUnitOfWork uow; 

    public CreateNewUserCommandHandler(
     IUnitOfWork uow) 
    { 
     this.uow = uow; 
    } 

    public void Handle(CreateNewUserCommand command) 
    { 
     // TODO Validation 

     var user = new User { Name = command.Name }; 

     this.uow.Users.InsertOnSubmit(user); 
    } 
} 

Вы даже можете добавить проверку в свой класс.