Модель домена C # + хранилище: где разместить код, который загружает объект

Question

У меня есть класс модели, который загружается из метода "GetById" в моем классе репозитория. Теперь мне нужно добавить к этой сущности дополнительные свойства, которые не сохраняются в базе данных, а рассчитываются по классу обслуживания. Что-то вроде:

public class MyEntity
{
    public int ThingId { get; set; };
    public string ThingName { get; set; }

    // Set from the service
    public int WooFactor { get; set; }
}

public class WooFactorGenerator
{
    public int CalculateWooFactor(MyEntity thing); // Hits other services and repo's to eventually determine the woo factor.
}

// Code to get a "MyEntity":

var myEntity = repo.GetById(1);
var gen = new WooFactorGenerator();
myEntity.WooFactor = gen.CalculateWooFactor(myEntity);

Итак, чтобы загрузить / насытить объект MyEntity, мне нужно загрузить его из БД, а затем вызвать генератор, чтобы определить «коэффициент woo» (хм). Куда должен идти этот код с архитектурной точки зрения? Актуальные мысли:

1) В репозитории: я чувствую, что слишком много ответственности перед репо, если добавляю его сюда.

2) В классе "MyEntity". Добавьте сюда код, который, возможно, лениво загружает WooFactor при обращении к нему. Это добавило бы много зависимостей к MyEntity.

3) Отдельный класс обслуживания - кажется излишним и ненужным.

Answer 1

Google CQRS. Что вам нужно сделать, это разделить проблемы чтения и записи. Если для расчета требуется что-то другое, кроме сущности, ваш ответ будет ясен.

Answer 2

• Если WooFactor зависит исключительно от MyEntity свойств, то это должно быть сделано внутри MyEntity
• Если для этого требуется внешняя информация (например, конфигурация, правила и т. Д.), То это должна быть отдельная служба вне репозитория . Я бы создал WooEntity здесь с этим дополнительным свойством.

В любом случае, он никогда не должен быть в Repository.

Answer 3

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

Используя ваш пример Это может выглядеть так:

public MyEntityService
{
  public MyEntity GetById(int id)
  {
    MyEntity myEntity = _repo.GetById(id);
    myEntity.WooFactor = _wooFactorGenerator.CalculateWooFactor(myEntity);
    return myEntity;
  }
}

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

Answer 4

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

Большой недостаток - управление зависимостями;я предполагаю, что подобные сценарии состоят в том, что физический доступ к данным абстрагирован - так что модель технически не привязана к SQL, файловой системе и т. д. Использование этого подхода позволит вам выставлять разные данные из разных репозиториев впоследовательным образом.

• Ваша идея использования отложенной загрузки хороша;и если вы абстрагируете технические зависимости, ваша основная проблема с этой опцией исчезнет.
• Отдельный класс обслуживания может показаться излишним, но это небольшая цена, если он означает, что он дает вам лучший контроль над зависимостями.1008 *