Сообщение Re[4]: Задача такая от 05.05.2019 12:53
Изменено 05.05.2019 13:26 igor-booch
Re[4]: Задача такая
D>Эти плюшки сделают вашу программу плохо поддерживаемой и в скором времени тормознутой.
Почему?
D>вы базу данных будете дизайнить по типу как выглядит форма
Если поэтому, то скажу так. У меня в 80% случаев navigation properties хорошо ложатся на форму, при том что структура БД под формы не подгоняю. В остальных 20%, да, нужны вспомогательные юайные сущности посредники между модельными сущности (из бд) и формой. Причём эти сущности посредники называю в терминах предметной области, а не безликим словом ViewModel. По поводу поддержки, часто имел проблемы с вьюмоделями-свалками, либо, наоборот, кучей хитро связанных мелких вьюделей. Любая прокладка должна быть функционально оправдана, иначе она приносит только убытки в виде накладных расходов на поддержку.
Почему?
D>вы базу данных будете дизайнить по типу как выглядит форма
Если поэтому, то скажу так. У меня в 80% случаев navigation properties хорошо ложатся на форму, при том что структура БД под формы не подгоняю. В остальных 20%, да, нужны вспомогательные юайные сущности посредники между модельными сущности (из бд) и формой. Причём эти сущности посредники называю в терминах предметной области, а не безликим словом ViewModel. По поводу поддержки, часто имел проблемы с вьюмоделями-свалками, либо, наоборот, кучей хитро связанных мелких вьюделей. Любая прокладка должна быть функционально оправдана, иначе она приносит только убытки в виде накладных расходов на поддержку.
Re[4]: Задача такая
D>Эти плюшки сделают вашу программу плохо поддерживаемой и в скором времени тормознутой.
Почему?
D>вы базу данных будете дизайнить по типу как выглядит форма
Если поэтому, то скажу так. У меня в 80% случаев navigation properties хорошо ложатся на форму, при том что структуру БД под формы не подгоняю. В остальных 20%, да, нужны вспомогательные юайные сущности посредники между модельными сущностями (из бд) и формой. Причём эти сущности посредники называю в терминах предметной области, а не безликим словом ViewModel. По поводу поддержки, часто имел проблемы с огромными
вьюмоделями-свалками, либо, наоборот, кучей хитро связанных мелких вьюмоделей. Любая прокладка должна быть функционально оправдана, иначе она приносит только убытки в виде накладных расходов на поддержку.
Почему?
D>вы базу данных будете дизайнить по типу как выглядит форма
Если поэтому, то скажу так. У меня в 80% случаев navigation properties хорошо ложатся на форму, при том что структуру БД под формы не подгоняю. В остальных 20%, да, нужны вспомогательные юайные сущности посредники между модельными сущностями (из бд) и формой. Причём эти сущности посредники называю в терминах предметной области, а не безликим словом ViewModel. По поводу поддержки, часто имел проблемы с огромными
вьюмоделями-свалками, либо, наоборот, кучей хитро связанных мелких вьюмоделей. Любая прокладка должна быть функционально оправдана, иначе она приносит только убытки в виде накладных расходов на поддержку.