Каков рекомендуемый шаблон для повторного использования контракта данных в качестве объектной модели в коде?

Question

Допустим, у меня есть служба и я публикую контракт, например

public class MyObject
{
    public int Foo { get; }

    public string Bar { set; }
}

. Я полагаю, что неправильно иметь «поведение» в контракте данных, например,

public class MyObject
{
    public int Foo { get; }

    public string Bar { set; }

    public void DoSomeAlgorithmWithMyProperties() { … }
}

Другими словами, контракты на данные должны быть просто сумками стоимости.

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

public class MyObjectInternal
{
    public int Foo { get; }

    public string Bar { set; }

    public class MyObjectInternal(int foo, string bar)
    {
        this.Foo = foo;
        this.Bar = bar;
    }

    public void DoSomeAlgorithmWithMyProperties() { … }
}

Другой способ - наследование

public class MyObjectInternal : MyObject
{
    public class MyObjectInternal(int foo, string bar)
    {
        this.Foo = foo;
        this.Bar = bar;
    }

    public void DoSomeAlgorithmWithMyProperties() { … }
}

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

public static class MyObjectAlgorithmDoer
{
     public static void DoSomeAlgorithmWithMyProperties(MyObject myObject) { … }
}

Answer 1

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

Answer 2

Я вижу, что вы можете добавить поведение в свой MyObject контракт двумя способами.Одним из способов является создание службы, которая взаимодействует с MyObject следующим образом: класс

public class MyObjectService 
{
    public void DoOperation(MyObject myObject) 
    {
    }
}

MyObjectService затем может быть вызван вашим приложением для выполнения операции.

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

Если, однако, ваша система сложна и развивается, то вы можете придерживаться доменно-управляемого дизайна .Из вики:

Предпосылкой доменного проектирования является следующее:

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

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

• https://airbrake.io/blog/software-design/domain-driven-design
• Многогранный курс: https://www.pluralsight.com/courses/refactoring-anemic-domain-model