ViewModel хранит в себе данные, да. Часть из них мне удобнее рендерить серверно, а часть на клиенте (начали использовать реакт, но при этом разом перевести весь проект на реат невозможно). Что в этом плохого? А что такое SRP не просветите? :)
Кстати о птичках — коль пошла такая пляска — можете потыкать у Json.NET свойство атрибута… как же его… по-моему NullValueHandling — и эта радость не будет отправлять на клиент null-поля (которые там будут undefined, но при проверке через if (object.Field) это не страшно).
В моем случае это не поможет. У меня поля не Null, они заполнены, но на клиенте не используются.
Ну и чтобы не разносить на два комментария — вы упомянули, что не для всех классов, которые помечены [DataContract] нужно генерировать интерфейсы. Но тогда получается что надо классы еще чем-то помечать. Мол — ты, типа, для этих генерируй, а для этих не генерируй. Можно пометить их тем же [TsInterface], что и является дефолтной практикой для R.T.
Не имею ничего против аттрибута [TsInterface] :)
А вот, кстати, переименования автоматического у меня нет. Как-то совсем даже забыл про него. Привык на сервере и на клиенте использовать PascalCase (и можете бить меня за это тапками). Но в следующей версии сделаю.
Стараюсь все же придерживаться общепринятых стандартов. В этом есть свои плюсы)
Актуален. При таком подходе мне на каждое свойство придется вешать по 2 аттрибута: TsField для корректной конвертации в ts и DataMember/JsonProperty для корректной сериализации/десериализации в Json.
Два аттрибута — это уже перебор, на мой взгляд.
Начал использовать еще до внедрения TypeScript'a. Это помогало не разломать фронтенд при рефакторинге бекэнда. С автоматической генерацией ts-интерфейсов эта проблема решается, но у нас проект большой и чистый js еще долго будет жить с нами.
Кроме того мне кажется важным явно помечать свойства, с которыми нужно работать на клиенте. Это во-первых, позволяет немного сократить объем ненужного траффика между клиентом и сервером, а во-вторых, на клиенте работать с чистыми интерфейсами без лишних серверных свойств.
Спасибо :)
Но атрибут [TsInterface] все равно нужен. DataContract может использоваться много для чего, и для всех классов, использующих его, генерить ts-интерфейсы не нужно, правильнее явно помечать классы, для которых нужны интерфейсы.
Я в своем проекте использую DataContract для помечания ViewModel и все свойства, необходимые на клиенте, явно помечаю DataMember-атрибутами. При конвертации в json использую JSON.Net, который из коробки прекрасно работает с dataconract'ом. Ну и ModelBinder для всего этого написан.
Это позволяет не боятся серверных рефаткорингов даже при использовании чистого js и явно указывать, какие свойства нужны на клиенте (часть свойств вью-моделей нужны только для серверного рендеринга, гонят туда-сюда данные смысла нет). Ну и кроме того в шарпе принято свойство называть с большой буквы, а в js — с маленькой.
Отсюда вопрос: поддерживает ли ваша библиотечка dataconract?
Кстати, при конвертации в typescript generic-классы и классы с наследованием корректно генерируются?
Есть большой минус: если я заполнил первый инпут и нажал таб (стандартное поведение), то фокус автоматически переходит на 3-й инпут.
Советую почитать, как с этим боролся Сергей Чикуёнок: chikuyonok.ru/2010/07/simple-things/
2. Если кабель редкий, то самовывоз из центра вполне себе выход. Это намного удобнее, чем мотаться на горбушку и другие электронные рынки (без гарантии найти нужный товар).
С регионами, конечно, сложнее. Но, опять же, если кабель редкий, и купить его негде, то переплатить 200р за доставку — единственный выход.
2. Если кабель редкий, то самовывоз из центра вполне себе выход. Это намного удобнее, чем мотаться на горбушку и другие электронные рынки (без гарантии найти нужный товар).
С регионами, конечно, сложнее. Но, опять же, если кабель редкий, и купить его негде, то переплатить 200р за доставку — единственный выход.
2 варианта:
1. Правой кнопкой по рабочему столу, в контекстном меню будет пункт про выбор графического адаптера.
2. Сенсорная кнопка с изображением батарейки должна не гореть зеленым.
Про SRP скорее теперь скорее согласен.
В моем случае это не поможет. У меня поля не Null, они заполнены, но на клиенте не используются.
Не имею ничего против аттрибута [TsInterface] :)
Стараюсь все же придерживаться общепринятых стандартов. В этом есть свои плюсы)
Два аттрибута — это уже перебор, на мой взгляд.
Кроме того мне кажется важным явно помечать свойства, с которыми нужно работать на клиенте. Это во-первых, позволяет немного сократить объем ненужного траффика между клиентом и сервером, а во-вторых, на клиенте работать с чистыми интерфейсами без лишних серверных свойств.
Но атрибут [TsInterface] все равно нужен. DataContract может использоваться много для чего, и для всех классов, использующих его, генерить ts-интерфейсы не нужно, правильнее явно помечать классы, для которых нужны интерфейсы.
из нее я бы хотел получить интерфейс вида
А в идеале даже без явного указания Name:
Это позволяет не боятся серверных рефаткорингов даже при использовании чистого js и явно указывать, какие свойства нужны на клиенте (часть свойств вью-моделей нужны только для серверного рендеринга, гонят туда-сюда данные смысла нет). Ну и кроме того в шарпе принято свойство называть с большой буквы, а в js — с маленькой.
Отсюда вопрос: поддерживает ли ваша библиотечка dataconract?
Кстати, при конвертации в typescript generic-классы и классы с наследованием корректно генерируются?
Советую почитать, как с этим боролся Сергей Чикуёнок: chikuyonok.ru/2010/07/simple-things/
С регионами, конечно, сложнее. Но, опять же, если кабель редкий, и купить его негде, то переплатить 200р за доставку — единственный выход.
С регионами, конечно, сложнее. Но, опять же, если кабель редкий, и купить его негде, то переплатить 200р за доставку — единственный выход.
писали бы хоть грамотно
1. Правой кнопкой по рабочему столу, в контекстном меню будет пункт про выбор графического адаптера.
2. Сенсорная кнопка с изображением батарейки должна не гореть зеленым.