Соответствующая модель и разделение классов классов (Архитектура)

Question

В настоящее время я задаюсь вопросом, каким образом предлагается разделить классы простой модели (например, используя их в Entity Framework, Web API, MVC, WCF ...) из своих частей логики приложения (задачи на стороне сервера, потоки и т. д.) с использованием принципа DRY.

Рассмотрим pseduo пример:

public class HorseOfDoom { 

    private Thread _hungerThread; 
    private Laser _headMountedLaser = new Laser(); 

    public int Age { get; set; } 
    public string Name { get; set; } 
    public int Health { get; set; } 
    public int HungerLevel { get; set; } 

    public HorseOfDoom() { 
      _hungerThread.Start(); 
    } 

    public void PewPew() { 
     _headMountedLaser.PewPew(); 
    } 

} 

В этом классе мы оба - свойства модели, описывающие модель (возраст, имя, ..), но также и нить методы. Я могу использовать этот класс в Entity Framework, WCF и т. Д., Но что, если я хочу использовать модель в клиентском приложении ASP.NET MVC без раскрытия методов, потоков? Должен ли я снова написать тот же класс? Нужны ли мне менеджеры, адаптеры и фасады? Могу ли я использовать шаблон класса друзей?

Answer 1

Используйте модель, подходящую для контекста. DRY не о повторении строк кода, а о повторении поведения. Ваша модель просмотра может иметь те же свойства (copy paste ftw), что и бизнес-модель, минус методы. Вы можете использовать Automapper для сопоставления друг с другом. Скорее всего, ваша модель представления будет иметь больше, чем те свойства, включая атрибуты проверки или другие данные, необходимые для представления в определенном формате.

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

Answer 2

Я понимаю, что сочетание, которое вы показываете в своем примере, не очень желательно - моей главной точкой критики будет нить, которая уже подразумевает конкретный способ поведения объекта. Вероятность высокая, что поток, содержащийся в самом классе, усложнит использование класса в некоторых средах. С моей точки зрения, платформа, которая интегрирует класс, должна иметь возможность выбирать, как организовать действия класса - конечно, класс может сделать некоторые ограничения типа «не использовать в отдельном потоке, поскольку класс не реализован в потокобезопасном режиме ».
Что касается пункта , следует ли совместить свойства и методы в классе: я не думаю, что есть четкий и всегда действительный ответ. Это зависит от того, насколько велика архитектура вашего приложения и готовы ли вы заплатить цену за разделение с точки зрения сложности и накладных расходов.
Концепция объединения свойств и методов в одном классе обычно называется "Domain Model". Это очень естественный подход к разработке сложной бизнес-логики.
Если у вас есть архитектура, которая очень хорошо разделяет слои, у вас будет модель домена в бизнес-логике, которая реализует бизнес-правила. Эти классы объединяют свойства и методы, но эти классы сопоставляются с более простыми версиями (например, DTO), которые переносят данные только на другие уровни. Таким образом, вы также отключите сервисный интерфейс от модели домена и измените их с минимальными влияниями на другие уровни. Например, если у вас есть сложные классы в модели домена, и вы хотите представить только часть этой информации в веб-интерфейсе или через сервисный уровень, вы можете создать один или несколько классов DTO, которые содержат именно те данные, которые необходимы. Изменения в модели домена не обязательно будут влиять на клиентов, так что вы получите свободу в этом отношении.
В более мелкой архитектуре, возможно, вам не потребуется разделять слои с помощью DTO, если вы можете жить с последствиями.
Что касается упомянутого примера WCF, у вас есть отдельные контракты на обслуживание и данные, которые вы обычно реализуете в разных классах. Если у вас есть дополнительные методы в классе, который служит в качестве контракта данных, эти методы не будут частью контракта с данными. Вам нужно будет явно указать методы, которые вы хотите опубликовать, часть контракта на обслуживание. Если вы не разделяете классы с клиентом службы (например, через библиотеку классов), клиент даже не знает, что эти методы существуют.