UI-ориентированная или доменная модель данных - плюсы и минусы

Question

Насколько тесно ваша модель данных соответствует вашему интерфейсу и модели домена?

Модель данных может быть очень близка к модели предметной области, если она имеет, например, таблицу Customer, таблицу Employee и т. Д.

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

Что оказалось для вас лучше?

Answer 1

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

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

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

информацию можно найти по этой схеме здесь:

http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx

Answer 2

Если у меня есть уровень обслуживания RESTful, то, что они выставляют модель домена. В этом случае пользовательский интерфейс (любой конкретный экран) вызывает ряд этих сервисов, и из собранных моделей доменов создается экран. В этом сценарии, хотя доменные модели всплывают до самого пользовательского интерфейса, уровень пользовательского интерфейса отбирает необходимые данные для построения своего конкретного экрана. В SO также есть несколько интересных вопросов об использовании доменной модели (аннотированной) для постоянства. Я хочу сказать, что доменные модели могут быть единственным источником правды. Он может выполнять работу по переносу данных, достаточно хорошо инкапсулируя логику. Я работал над проектами, в которых было много стандартного кода, переводящего каждую модель предметной области в DTO, VO, DO и что-то еще. Многое из этого выглядело совершенно ненужным, и в большинстве случаев это было связано с привычкой.

Answer 3

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