На уровне модели, это хорошая идея для составления типов с идентификаторами, в отличие от прямых ссылок?

Question

На уровне модели, это хорошая идея для составления типов с идентификаторами, в отличие от прямых ссылок?

1

Хотя этот вопрос находится в контексте MVVM, я думаю, что его можно обобщить на любую архитектуру MV *.

При создании моего модельного слоя я привык непосредственно ссылаться на объекты, чтобы представлять отношения, как таковые:

class Course {
 CourseID ID { get; }
 string Name { get; }
}
class Student {
 IEnumerable<Course> EnrolledCourses { get; }
}

Однако я обнаружил, что восстановление таких иерархий объектов из хранилища становится все более обременительным. Без преимуществ DI на уровне модели я остался перед несчастным выбором использования тяжелой ORM со всеми сопутствующими атрибутами и другими головными болями или с использованием микро-ORM (мои предпочтения), а затем кропотливо восстанавливая графы объектов рукой.

Я играю с идеей полностью отдавать прямые ссылки в пользу чего-то вроде:

class Course {
 CourseID ID { get; }
 string Name { get; }
}
class Student {
 IEnumerable<CourseID> EnrolledCourses { get; }
}

Таким образом, мой модельный слой начинает более напоминать реляционные данные, которые, как я всегда предполагал, традиционно не одобрялись (таким образом, предпочтение ОРМ).

В моем коде данные приложения обычно отображаются на более высоких уровнях по шаблону репозитория, как реактивные каналы и/или iEnumerables. Это упрощает получение и отображение соответствующих данных по запросу посредством запросов и/или фильтров ключами. Не так просто, как прямая ссылка, но близко.

Итак - какой главный аргумент AGAINST для моделирования объектов домена без ссылок на другие типы? Кроме того, я попытался найти дискуссию об этом, но не видел многого, может быть, я не вижу правильных условий поиска?

tempy 21 май 2014, в 18:04

Источник

Теги:

c#

oop

model

design

composition

1 ответ

Ещё вопросы

MikeSW · Accepted Answer · 2014-05-21T12-46-00.000Z

В любом приложении, которое вы хотите поддерживать, вам необходимо уважать разделение проблем. MV * всегда является частью уровня пользовательского интерфейса, и большую часть времени вы также имеете уровень Business (домен) и уровень сохранения (DAL).

SoC означает, что вы должны сосредоточиться на одном слое в то время. ViewModel предназначен для модели View, Domain заботится только о бизнесе, а модель Persistence Model знает о сохранении и запросе. Они связаны друг с другом, но не то же самое, и лучше думать о них как о разных.

Когда вы моделируете Domain, вам не нравятся другие слои, вы хотите лучше всего представлять бизнес-концепцию (и это очень сложно, поскольку многие из них кажутся легкими для моделирования, но это ловушка!) И варианты использования этих понятий. Здесь нет ссылок, есть только бизнес-процессы с использованием бизнес-концепций, т.е. Вы должны думать на более высоком уровне не на техническом уровне, даже если вы пишете код.

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

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

Имейте в виду, что для разных контекстов вам действительно не нужен полный объект, а только его "короткая" форма, которая обычно означает ссылку (как в Id). Но с точки зрения контекста эта ссылка представляет собой концепцию. Обратите внимание, что сущности или ссылки не существуют для навигационных целей. Они есть, потому что они помогают определить концепцию домена.

Кроме того, нет смысла определять бизнес-объект с единственной целью действовать как контейнер для других. При моделировании домена, имеют отношение следует рассматривать как определяются.

Вы должны ознакомиться с CQRS (отделяя записи от чтения). Это позволит экономить/восстанавливать бизнес-модель тривиально, позволяя вам получать запросы с запросами. И вам не понадобится ORM.

В нижней строке вы должны моделировать вещи в соответствии с уровнем (заботой), в котором вы работаете. Затем используйте mappers для "перевода" соответствующей модели из одного слоя/контекста в другой. Не пытайтесь создать конечную модель, которая будет соответствовать всем целям.