Есть ли хорошие шаблоны / принципы для разделения логики создания и обновления?

Question

На простом примере пользователя, исходя из своего опыта, я обнаружил, что всегда есть немного другая часть проверки / логики для выполнения в зависимости от того, создаете ли вы или обновляете пользователя (эта проблема распространяется на обновление другого домена сущности тоже). Код быстро становится спагетти, когда вы добавляете либеральные посыпания с обоснованием, таким как «Просто сделайте эту проверку для пользователя при их обновлении» и «ох, просто сделайте эту проверку, логика, вставьте при создании пользователя»

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

Спасибо

Answer 1

Что ж, в основном есть два шаблона на выбор:

1. Создайте полностью отдельные случаи для добавления и обновления.
2. Создайте один случай, который обрабатывает как добавление, так и обновление.

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

Попытка создать что-то промежуточное, скорее всего, приведет к недостаткам обоих шаблонов.

Answer 2

Я бы использовал Шаблон шаблона для этой ситуации. По сути, вы можете поместить весь дублирующий код в базовый класс, и унаследованные классы реализуют специфику. Простой пример кода psuedo будет выглядеть так:

IRep

class IRep
{
   void Add(object a);
   void Remove(object a);
}

BaseRep

abstract class BaseRep : IRep
{
    void Add(object a)
    {
       if(OkToAdd(a))
       {
          // Common Rep code here
       }
    }

    void Remove(object a)
    {
       if(OkToRemove(b))
       {
          // Common Rep code here
       }
    }

    abstract bool OkToAdd(object a);
    abstract bool OkToRemove(object a);
}

MyRep1

class MyRep1 : BaseRep
{
    bool OkToAdd(object a)
    {
       // Add specific checks here for MyRep1
    }

    bool OkToRemove(object a)
    {
       // Add specific checks here for MyRep1
    }
}

MyRep2

class MyRep2 : BaseRep
{
    bool OkToAdd(object a)
    {
       // Add specific checks here for MyRep2
    }

    bool OkToRemove(object a)
    {
       // Add specific checks here for MyRep2
    }
}

Answer 3

Хорошо, так что я на несколько лет дальше в своей карьере, и теперь у меня есть понимание ряда подходов при разработке / понимании программного обеспечения.

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

При таком подходе намеренные и бизнес-правила быстро теряются.

Один из способов облегчить это - использовать подход DDD и тщательно моделировать поведение так, чтобы только соответствующее состояние изменялось и затем сохранялось (скорее всего, для агрегата или объекта сущности / значения в этом агрегате).Это помогает обеспечить наличие контролируемой истории благодаря операции, явно указывающей, какое состояние изменяется.Например:

Customer.AddUsername(string username)

Где этот метод будет обновлять имя пользователя с областью действия, чтобы бизнес-правила играли в операции.

Answer 4

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

Конечно здесь задействована другая логика.

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

Answer 5

Мне нравится, когда они полностью разделены.Хотя это может выглядеть как дублирование кода, оно позволяет независимо развивать эти действия в будущем.И они могут сильно отличаться друг от друга: при создании могут быть некоторые поля, которые не требуются или даже не могут быть установлены, и в каждом случае может быть проверено множество различных правил.Если вы полностью разделите эти действия, то у вас будет полная свобода в том, как их развить.