Классы, не относящиеся к данным, являются частью модели?

Question

Классы, не относящиеся к данным (которые не представляют ничего в базе данных), по-прежнему считаются частью доменной модели приложения или нет? Вы бы соединили их с вашей моделью домена Linq2Sql или где-нибудь еще?

Редактировать : информация о классах. Например, у меня есть класс «StatusMessage», который создается при определенных обстоятельствах и может быть отброшен или отображен для пользователя. Это не имеет ничего общего с данными из базы данных (ни поиска, ни хранения). Другой пример - класс «Приглашение». Пользователи на моем сайте могут «приглашать» друг друга, и, если они это сделают, создается класс приглашений, который зашифрует некоторую информацию, а затем выведет ссылку, которую пользователь может дать кому-то еще. У меня> 25 из этих классов. Они не для передачи данных, они действительно работают, но они не связаны с базой данных, и я бы не сказал, что они все «помощники» ?! ....

Answer 1

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

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

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

Answer 2

Это зависит.

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

Если это какие-то помощники, то это будет зависеть.

ДОБАВЛЕНО: прочитав дополнительную информацию об этих классах, я думаю, что многие из них заслуживают достойного места в вашей бизнес-логике. Вы можете провести черту между моделью предметной области и бизнес-логикой. Я полагаю, вы считаете, что ваша модель домена содержит только классы отображения базы данных, и это нормально. Но есть и бизнес-правила, рабочие классы, которые принимают вводимые пользователем данные, обрабатывают их, принимают решения и вызывают необходимые операции для их принятия. Эти могут включать CRUDing что-либо в базу данных, отправку уведомлений по электронной почте, инициирование задач планировщика, уведомление других служб и т. Д. Для многих действий их результат будет только отдаленно отражаться в базе данных, некоторые значения могут быть изменены, но не могут как полное состояние бизнес-объекта переходит непосредственно в базу данных. Следовательно, было бы целесообразно хранить их вместе в выделенном слое.

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

При использовании StatusMessage может не потребоваться отдельный класс для этого. Сообщения относятся к уровню просмотра. Класс может просто решить, какое сообщение показывать, но тогда реальная работа с дисплеем будет происходить ближе к пользовательскому интерфейсу.