Сообщение Re[4]: Про бизнес-объекты: для сохранения, для API, для внут от 26.09.2017 20:27
Изменено 26.09.2017 20:47 Shmj
Re[4]: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, bnk, Вы писали:
bnk>Ясно почему — аттрибуты сериализации в базу полезут в Web API, и наоборот.
А чем они мешают на практике?
bnk>Данные, нужные только для UI, нужно будет маркировать "не сохранять", "не экспортировать", ну и т.д.
Правильно, пометить что те или иные не нужно экспортировать. Это разве не логично и правильно? Пометил -- а система разберется.
bnk>Типы данных будет покорежены — возьмем например enum. В базе нужет int, в UI — string. Что делаем?
Так это по отдельности указывается с помощью атрибутов или Fluent
bnk>Нафик конструкторы. Бесполезная вещь в данном случае. Данные проверяются строго на пользовательском вводе, и больше нигде. А там WebAPI и всякие [Required], заботиться не о чем.
Данные поступают не только от пользователя. Идея такая -- нельзя создать объект класса, чтобы в нем не было обязательных полей. Зачем тогда вообще конструкторы с параметрами нужны? Или вы их вообще не используете никогда, отказались от концепции конструктора как такового?
bnk>Все равно в таких классах как правило дофигищи полей, не засовывать же их все в параметры конструктора?
Но не все же из них обязательные?
bnk>Ясно почему — аттрибуты сериализации в базу полезут в Web API, и наоборот.
А чем они мешают на практике?
bnk>Данные, нужные только для UI, нужно будет маркировать "не сохранять", "не экспортировать", ну и т.д.
Правильно, пометить что те или иные не нужно экспортировать. Это разве не логично и правильно? Пометил -- а система разберется.
bnk>Типы данных будет покорежены — возьмем например enum. В базе нужет int, в UI — string. Что делаем?
Так это по отдельности указывается с помощью атрибутов или Fluent
bnk>Нафик конструкторы. Бесполезная вещь в данном случае. Данные проверяются строго на пользовательском вводе, и больше нигде. А там WebAPI и всякие [Required], заботиться не о чем.
Данные поступают не только от пользователя. Идея такая -- нельзя создать объект класса, чтобы в нем не было обязательных полей. Зачем тогда вообще конструкторы с параметрами нужны? Или вы их вообще не используете никогда, отказались от концепции конструктора как такового?
bnk>Все равно в таких классах как правило дофигищи полей, не засовывать же их все в параметры конструктора?
Но не все же из них обязательные?
Re[4]: Про бизнес-объекты: для сохранения, для API, для внут
Здравствуйте, bnk, Вы писали:
bnk>Ясно почему — аттрибуты сериализации в базу полезут в Web API, и наоборот.
А чем они мешают на практике?
bnk>Данные, нужные только для UI, нужно будет маркировать "не сохранять", "не экспортировать", ну и т.д.
Правильно, пометить что те или иные не нужно экспортировать. Это разве не логично и правильно? Пометил -- а система разберется.
bnk>Типы данных будет покорежены — возьмем например enum. В базе нужет int, в UI — string. Что делаем?
Так это по отдельности указывается с помощью атрибутов или Fluent
bnk>Нафик конструкторы. Бесполезная вещь в данном случае. Данные проверяются строго на пользовательском вводе, и больше нигде. А там WebAPI и всякие [Required], заботиться не о чем.
Данные поступают не только от пользователя. Идея такая -- нельзя создать объект класса без обязательных полей. Зачем тогда вообще конструкторы с параметрами нужны? Или вы их вообще не используете никогда, отказались от концепции конструктора как такового?
bnk>Все равно в таких классах как правило дофигищи полей, не засовывать же их все в параметры конструктора?
Но не все же из них обязательные?
bnk>Ясно почему — аттрибуты сериализации в базу полезут в Web API, и наоборот.
А чем они мешают на практике?
bnk>Данные, нужные только для UI, нужно будет маркировать "не сохранять", "не экспортировать", ну и т.д.
Правильно, пометить что те или иные не нужно экспортировать. Это разве не логично и правильно? Пометил -- а система разберется.
bnk>Типы данных будет покорежены — возьмем например enum. В базе нужет int, в UI — string. Что делаем?
Так это по отдельности указывается с помощью атрибутов или Fluent
bnk>Нафик конструкторы. Бесполезная вещь в данном случае. Данные проверяются строго на пользовательском вводе, и больше нигде. А там WebAPI и всякие [Required], заботиться не о чем.
Данные поступают не только от пользователя. Идея такая -- нельзя создать объект класса без обязательных полей. Зачем тогда вообще конструкторы с параметрами нужны? Или вы их вообще не используете никогда, отказались от концепции конструктора как такового?
bnk>Все равно в таких классах как правило дофигищи полей, не засовывать же их все в параметры конструктора?
Но не все же из них обязательные?