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

bnk>>Данные, нужные только для UI, нужно будет маркировать "не сохранять", "не экспортировать", ну и т.д.
S>Правильно, пометить что те или иные не нужно экспортировать. Это разве не логично и правильно? Пометил -- а система разберется.

Ну конечно :) А атрибуты где определены? В слое данных (EF?) Добавляем референс на него, ага.
Дальше, атрибуты для WCF? Конечно, добавляем референс на него тоже. Дальше, что там, WebAPI, JSON, XML? да, еще референсы.
Потом нужно передать пару дополнительных флажок для UI, и пару списков для комбобоксов? Конечно, добавляем поля и помечаем его всем чем нужно, для всех модулей не забыв.
Для JSON-сервиса понадобился штамп времени? Добавляем...

В общем я к чему — в результате получится класс данных, который "знает" все обо всех. Слишком много знает.
Например, в конкретном месте, может быть непонятно, какие проперти предназначены для данной подсистемы, а какие — для другой.
При модификации одной системы (базы например) придется держать в голове, как нужно пометить данную проперти, чтобы ничего не сломалось,
и чтобы она не прилетела, куда не нужно.

bnk>>Типы данных будет покорежены — возьмем например enum. В базе нужет int, в UI — string. Что делаем?

S>Так это по отдельности указывается с помощью атрибутов или Fluent

То есть сделать int/enum? а потом типа навешивать гроздьями атрибуты-конвертеры в строку для WCF или API? или сделать строкой?

bnk>>Нафик конструкторы. Бесполезная вещь в данном случае. Данные проверяются строго на пользовательском вводе, и больше нигде. А там WebAPI и всякие [Required], заботиться не о чем.

S>Идея такая -- нельзя создать объект класса, чтобы в нем не было обязательных полей. Зачем тогда вообще конструкторы с параметрами нужны? Или вы их вообще не используете никогда, отказались от концепции конструктора как такового?

Если больше одного-двух-трех — нет, в лес. Делаем проперти. Для DTO — да, никаких конструкторов.

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

bnk>>Данные, нужные только для UI, нужно будет маркировать "не сохранять", "не экспортировать", ну и т.д.
S>Правильно, пометить что те или иные не нужно экспортировать. Это разве не логично и правильно? Пометил -- а система разберется.

Ну конечно :) А атрибуты где определены? В слое данных (EF?) Добавляем референс на него, ага.
Дальше, атрибуты для WCF? Конечно, добавляем референс на него тоже. Дальше, что там, WebAPI, JSON, XML? да, еще референсы.
Потом нужно передать пару дополнительных флажков для UI, и пару списков для комбобоксов? Конечно, добавляем поля и помечаем их всем чем нужно, для всех модулей не забыв.
Для JSON-сервиса понадобился штамп времени? Добавляем...

В общем я к чему — в результате получится класс данных, который "знает" все обо всех. Слишком много знает.
Например, в конкретном месте, может быть непонятно, какие проперти предназначены для данной подсистемы, а какие — для другой.
При модификации одной системы (базы например) придется держать в голове, как нужно пометить данную проперти, чтобы ничего не сломалось,
и чтобы она не прилетела, куда не нужно.

bnk>>Типы данных будет покорежены — возьмем например enum. В базе нужет int, в UI — string. Что делаем?

S>Так это по отдельности указывается с помощью атрибутов или Fluent

То есть сделать int/enum? а потом типа навешивать гроздьями атрибуты-конвертеры в строку для WCF или API? или сделать строкой?

bnk>>Нафик конструкторы. Бесполезная вещь в данном случае. Данные проверяются строго на пользовательском вводе, и больше нигде. А там WebAPI и всякие [Required], заботиться не о чем.

S>Идея такая -- нельзя создать объект класса, чтобы в нем не было обязательных полей. Зачем тогда вообще конструкторы с параметрами нужны? Или вы их вообще не используете никогда, отказались от концепции конструктора как такового?

Если больше одного-двух-трех — нет, в лес. Делаем проперти. Для DTO — да, никаких конструкторов.