Вопрос о репозиториях и их методах сохранения для объектов домена

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

Используйте объекты значений для своих адресов

Во-первых, вы можете применить здесь концепцию Value Objects (VO). В вашем случае это будет Адрес. Разница между объектом значения и объектом сущности состоит в том, что сущности имеют идентичность; ВО нет. Идентичность ВО на самом деле является суммой его свойств, а не уникальной идентичностью. В книге Быстрая разработка доменного диска (это также бесплатную загрузку PDF-файла), он очень хорошо объясняет это, заявляя, что адрес на самом деле является просто точкой на Земле и не требует отдельной идентичности, подобной SocialSecurity, как человек. Эта точка на Земле представляет собой комбинацию улицы, номера, города, индекса и страны. Он может иметь значения широты и долготы, но по определению это даже ВО, потому что это комбинация двух точек.

Используйте Сервисы для объединения ваших сущностей в единую сущность, чтобы действовать.

Также не забывайте о концепции Сервисов в учебнике DDD. В вашем примере эта услуга будет:

public class PersonCompanyService
{
  void SavePersonCompany(IPersonCompany personCompany)
  {
    personRepository.SavePerson();
    // do some work for a new company, etc.
    companyRepository.SaveCompany();
  }
}

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

ORM обычно требуют идентификации, и точка.

Теперь, как бы вы записали VO адреса в базу данных? Очевидно, вы бы использовали IAddressRepository. Но поскольку большинство ORM (например, LingToSql) требуют, чтобы все объекты имели идентификатор, вот трюк: пометьте идентификатор как внутренний в вашей модели, чтобы он не отображался за пределами вашего уровня модели. Это собственный совет Стивена Сандерсона.

public class Address
{
  // make your identity internal
  [Column(IsPrimaryKey = true
    , IsDbGenerated = true
    , AutoSync = AutoSync.OnInsert)]
  internal int AddressID { get; set; }

  // everything else public
  [Column]
  public string StreetNumber { get; set; }
  [Column]
  public string Street { get; set; }
  [Column]
  public string City { get; set; }
  ...
}

Исходя из моего недавнего опыта использования шаблона репозитория, я думаю, вам было бы полезно использовать общий репозиторий, теперь уже распространенный IRepository T. Таким образом вам не нужно будет добавлять методы репозитория, такие как SavePerson (Person person). Вместо этого у вас будет что-то вроде:

IRepository<Person> personRepository = new Repository<Person>();
Person realPerson = new Person();
personRepository.SaveOrUpdate(realPerson);

Этот метод также хорошо подходит для разработки через тестирование и имитации.

Я считаю, что вопросы о поведении в вашем описании будут касаться домена, возможно, вам следует иметь метод AddCompany в своем классе Person и изменить свойство Company на

public Company Company { get; private set; }

Моя точка зрения; моделируйте домен, не беспокоясь о том, как данные будут сохраняться в базе данных. Это проблема службы, которая будет использовать модель вашей предметной области.

Вернувшись в репозиторий, взгляните на этот post для хорошего объяснения IRepository через LinqToSql. В блоге Майка есть много других сообщений о репозиториях. Когда вы все же решите выбрать ORM, я могу порекомендовать HHibernate вместо LinqToSql, последний теперь не функционирует, а у NHibernate есть отличное сообщество поддержки.