Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, GreenTea, Вы писали:

B>>>В этом случае 90% кода можно вынести в общие классы. Сюрприз!
GT>>Не, не, не. Возможно не так выразился. Я имел в виду что для одной и той же вьюхи 90% полей совпадают, а 10% отличаются (типа: берутся из вложенных сущностей, конвертируется представление [к примеру для даты]).
B>И даже в этом случае 90% кода можно вынести в общие классы.

GT>>Поэтому модель делалась очень гибкой...
GT>>Совершенно не мапится на представление один к одному. Аналитики составляющие требование — класть хотели на нашу супер модель.
B>Ну, то есть, в итоге, модель оказалась недостаточно гибкой.

Та нет, модель как раз это самое гибкое. А представление может меняться от итерации к итерации. Что же каждый раз базу менять?

GT>>https://www.dropbox.com/s/olgcy4vx3grlwl3/123.png
B>Ага. Теперь понятно чем руководствуются правительственные моделлеры в USA.

Зато теперь вы видите, что модели могут быть сложными. А то такое ощущение у меня сложилось, что вы живете в каком то простом мире

GT>>А теперь представте что надо вставить данные по сотруднику, его имя, должность, телефон. Это все берется из различный сущностей иерархии модели.
B>Мне представлять не нужно. В UI нет проблем достать что-то через пару свойств.

Ага, тянуть на представления всю иерархию, и пусть ищут, что им нужно! Отличный подход! А то что лишние данные передаются, то что это как минимум не секюрно, кого это волнует?)

GT>>Ну представте себе да, а вы бы как делали?
B>Разбил бы через композицию и наследование в иерархию.

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