Jaka jest idea stosowania prywatnych setterów we właściwościach modelu?

0

Przeglądałem kilka kursów C# tworzonych przez "znane" osoby i przewija się w wielu motyw niepublicznych setterów w klasach modeli.

public class User
  {
      public Guid Id { get; protected set; }
      public string Email { get; protected set; }
      public string Password { get; protected set; }
      public string Salt { get; protected set; }
      public string Username { get; protected set; }
      public string FullName { get; protected set; }
      public string Role { get; protected set; }
      public DateTime CreatedAt { get; protected set; }
      public DateTime UpdatedAt { get; protected set; }

      protected User()
      {
      }

      public User(Guid userId, string email, string username, string role,
          string password, string salt)
      {
          Id = userId;
          SetEmail(email);
          SetUsername(username);
          SetRole(role);
          SetPassword(password, salt);
          CreatedAt = DateTime.UtcNow;
      }
      public void SetUsername(string username)
      {
          if (!NameRegex.IsMatch(username))
          {
              throw new DomainException(ErrorCodes.InvalidUsername,
                  "Username is invalid.");
          }

          if (String.IsNullOrEmpty(username))
          {
              throw new DomainException(ErrorCodes.InvalidUsername,
                  "Username is invalid.");
          }

          Username = username.ToLowerInvariant();
          UpdatedAt = DateTime.UtcNow;
      }
      //dalszy kod
  }
  1. Jak teraz wypełnić taki model danymi np z bazy?
  2. W warstwie wyższej czytam sobie dane z bazy i co, za kazdym razem muszę wywołać konstruktor modelu z parametrami (danymi z bazy)?
  3. W takim przypadku za każdym razem będę miał datę utworzenia jako datę bierzącą a nie tą z bazy?
  4. Guid muszę za każdym razem przekazać ręcznie w konstruktorze?
  5. Co jeśli mój model będzie zawierał 50 właściwości, wtedy wszystkie mam wprowadzać jako parametry konstruktora?
0

To wygląda jak model bazodanowy dla NHibernate.

  1. NHibernate sobie radzi z setterami protected jak dobrze pamiętam.
  2. Konstruktor dodający datę utworzenia będzie wywołany kiedy utworzysz obiekt ręcznie. ORM skorzysta z konstruktora bez parametrów.
  3. Jak Twój model ma 50 właściwości to albo go po bożemu podzielisz, albo pokutą będzie wprowadzanie tych parametrów

Niepubliczny setter jest po to żeby zachować enkapsulację. Dane mogą być zmieniane tylko przez metody tej klasy. Protected zamiast private jest na 90% hackiem pozwalającym użyć upośledzonego ORMa, który inaczej nie poradził by sobie z utworzeniem obiektu.

0

Zaletą enkapsulacji jest to, że klasa, która trzyma te dane jest odpowiedzialna za poprawność tych danych (metoda SetUsername). Kod pilnujący tego masz w jednym miejscu i nie ma możliwości zmiany właściwości bez jego użycia. Możesz nie dostrzegać zalet enkapsulacji jak piszesz sobie mały domowy projekcik. Jednakże w projektach utrzymywanych latami i/lub pisanych przez wiele osób szybko myślę je docenisz.

1 użytkowników online, w tym zalogowanych: 0, gości: 1