Комментарии 14
Зачем новичкам WindowsForms, когда UWP шагает по планете, а WPF — стандарт де-факто для десктопа? Именование свойств — смесь верблюда и змеи. MVVM? — не, не слышал.
Если честно, представления о работе с API именно вконтакте не появилось — стандартный token flow. И был задействован всего 1 метод. Надеялся на обзор занимательных с точки зрения авторов возможностей API сервиса. В частности, можно сделать пример по интеграции торговли ВКонтакте через собственный шлюз на C# с какой-нибудь CMS с интернет-магазином. Ну или хотя бы с уведомлением в Slack )))
Присоединяюсь к комментарию dmitry_dvm.
От себя добавлю пару ресурсов:
1. Конвенции по именованиям
2. Туториал о том, что такое и зачем нужены принципы SOLID
Чтобы статья была хоть как-то полезна для новичков, я бы посоветовал после просмотра вышеописанных ресурсов провести рефакторинг кода и выложить на github или другой аналогичный сервис, и ссылку добавить в статью. Ну и реализовать это на WPF и/или UWP для личного опыта. Обработка исключений тоже очень важный аспект, который хоть в каком-то виде должен присутствовать в приведенном коде.
От себя добавлю пару ресурсов:
1. Конвенции по именованиям
2. Туториал о том, что такое и зачем нужены принципы SOLID
Чтобы статья была хоть как-то полезна для новичков, я бы посоветовал после просмотра вышеописанных ресурсов провести рефакторинг кода и выложить на github или другой аналогичный сервис, и ссылку добавить в статью. Ну и реализовать это на WPF и/или UWP для личного опыта. Обработка исключений тоже очень важный аспект, который хоть в каком-то виде должен присутствовать в приведенном коде.
Уважаемый автор, призываю задуматься в первую очередь о необходимости статья на хабре. Безусловно, конкретно для Вас профит очевиден — неплохой фидбек т сообщества. Но по факту, статью бы спрятать в черновик.
2016 год, если есть очевидная необходимость не в web, а именно desktop, и если уж завязываться только на Windows, то либо UWP, либо WPF (хоть об этом и было выше).
2016 год, если есть очевидная необходимость не в web, а именно desktop, и если уж завязываться только на Windows, то либо UWP, либо WPF (хоть об этом и было выше).
UWP — это про windows 10 и windows 10 mobile. Пожалуйста, спуститесь на землю и оцените соотношение пользователей XP/7/8 и 10 прежде чем навязывать кому-то UWP.
Что касается WPF, предлагаю Вам сравнить насыщенные видимыми контролами приложения WPF и Win forms по потреблению ресурсов перед тем, как предлагать кому-то WPF
Что касается WPF, предлагаю Вам сравнить насыщенные видимыми контролами приложения WPF и Win forms по потреблению ресурсов перед тем, как предлагать кому-то WPF
О, сейчас мы уйдем в холивар, вестимо…
Для начала, если перечитать моее сообщение внимательно (!), то можно уловить цепочку, то можно увидеть приоритетность при выборе используемых инструментов.
Далее, про «спуститесь на землю» и «навязывать». Автор — новичек и определил целевую аудиторию поста — новички. Соответственно, к моменту, когда знания будут применятся в реальных проектах, скорее всего пройдет какое-то время. И с течением времени «пользователей XP/7» станет еще меньше, не говоря уже о 8.x, для которых переезд на 10 практически безболезненый.
Про WPF… то есть оптимизация отрисовки через DirectX, а не через обращение к ядру ОС; удобство разработки (номарльный Data Binding) с возможностью постороения логичной трехслойной архитектуры, а не через спагетти-код; шикарные возможности кастомизации UI и прочее это все в зачет не идет? Ну и да, потребление ресурсов, я уверене, не от кривого WPF, а неумения им пользоваться (возможно, по причине того, что пересаживаются с WinForms толком не разобравшись).
И да, я не навязываю, это Ваш выбор использовать инструмент, к которому вы привыкли XP+WinForms — прямой путь «вернуть себе свой 2007-й год».
Для начала, если перечитать моее сообщение внимательно (!), то можно уловить цепочку, то можно увидеть приоритетность при выборе используемых инструментов.
Далее, про «спуститесь на землю» и «навязывать». Автор — новичек и определил целевую аудиторию поста — новички. Соответственно, к моменту, когда знания будут применятся в реальных проектах, скорее всего пройдет какое-то время. И с течением времени «пользователей XP/7» станет еще меньше, не говоря уже о 8.x, для которых переезд на 10 практически безболезненый.
Вот вам график на май 2016 дял Северной Америки
Про WPF… то есть оптимизация отрисовки через DirectX, а не через обращение к ядру ОС; удобство разработки (номарльный Data Binding) с возможностью постороения логичной трехслойной архитектуры, а не через спагетти-код; шикарные возможности кастомизации UI и прочее это все в зачет не идет? Ну и да, потребление ресурсов, я уверене, не от кривого WPF, а неумения им пользоваться (возможно, по причине того, что пересаживаются с WinForms толком не разобравшись).
И да, я не навязываю, это Ваш выбор использовать инструмент, к которому вы привыкли XP+WinForms — прямой путь «вернуть себе свой 2007-й год».
Простите, но это похоже на проповедь неофитов, которые ранее то же самое говорили про COM, Silverlight, WinRT и WPF. Что ни чуть не помешало мелкомягким забить на эти некогда перспективные технологии. На чём же, спрашивается, основан Ваш оптимизм в отношении будущего UWP?
Нет, я не собираюсь устраивать холивар или гадить UWP. Просто не вижу смысла закрючиваться на технологии, ограниченной одной единственной осью как для пользователя, так и для разработчика.
== Про WPF… то есть оптимизация отрисовки через DirectX, а не через обращение к ядру ОС
сделанная хуже некуда https://jeremiahmorrill.wordpress.com/2011/02/14/a-critical-deep-dive-into-the-wpf-rendering-system/
== удобство разработки (номарльный Data Binding)
нормальным его считают те, кто не знаком с FRP и не умеет делать WinForms без SmartUI и визуального редактора. А вообще-то Data Binding через IPropertyChanged это просто писец какой отстой — утечки памяти, дыра в типизации, нельзя нормально дебажить и вопиющая неэффективность
== возможностью постороения логичной трехслойной архитектуры
MVVM логичная? да вы шо!
== шикарные возможности кастомизации UI
без производительности может идти лесом. Спросите у любого юзера, что он думает о тормознутых программах, ага?
== Ну и да, потребление ресурсов, я уверене, не от кривого WPF, а неумения им пользоваться
что именно даёт вам эту уверенность?
== я не навязываю, это Ваш выбор использовать инструмент, к которому вы привыкли XP+WinForms — прямой путь «вернуть себе свой 2007-й год».
Я ни делал никаких выборов и ни к чему не привык. У меня абсолютно прагматичный подход к выбору фреймворка. Если надо сделать примитивную хрень для отображения и поста няшных котиков — Electron либо UWP. Если под виндовз, и основное перформанс — MFC. Если на производительность можно немножко положить в пользу удешевления разработки — WinForms
Нет, я не собираюсь устраивать холивар или гадить UWP. Просто не вижу смысла закрючиваться на технологии, ограниченной одной единственной осью как для пользователя, так и для разработчика.
== Про WPF… то есть оптимизация отрисовки через DirectX, а не через обращение к ядру ОС
сделанная хуже некуда https://jeremiahmorrill.wordpress.com/2011/02/14/a-critical-deep-dive-into-the-wpf-rendering-system/
== удобство разработки (номарльный Data Binding)
нормальным его считают те, кто не знаком с FRP и не умеет делать WinForms без SmartUI и визуального редактора. А вообще-то Data Binding через IPropertyChanged это просто писец какой отстой — утечки памяти, дыра в типизации, нельзя нормально дебажить и вопиющая неэффективность
== возможностью постороения логичной трехслойной архитектуры
MVVM логичная? да вы шо!
== шикарные возможности кастомизации UI
без производительности может идти лесом. Спросите у любого юзера, что он думает о тормознутых программах, ага?
== Ну и да, потребление ресурсов, я уверене, не от кривого WPF, а неумения им пользоваться
что именно даёт вам эту уверенность?
== я не навязываю, это Ваш выбор использовать инструмент, к которому вы привыкли XP+WinForms — прямой путь «вернуть себе свой 2007-й год».
Я ни делал никаких выборов и ни к чему не привык. У меня абсолютно прагматичный подход к выбору фреймворка. Если надо сделать примитивную хрень для отображения и поста няшных котиков — Electron либо UWP. Если под виндовз, и основное перформанс — MFC. Если на производительность можно немножко положить в пользу удешевления разработки — WinForms
Вот интересный пример работы с VK-API.
У вас представления о C#, net framework и Windows Forms на уровне эмигранта из дельфей начала нулевых.
Вы представили абсолютно кривой код — грязный и не работающий. И это при том, что поставленная задача — всего лишь отправить http запросы двух видов! Например выбранный способ авторизации AuthorizationForm, WebBrowser, DocumentCompleted — дичайшее усложнение примитивнейшей задачи отправки http POST запроса с последующим разбором ответа.
В качестве средства для упрощения http клиента выбрана абсолютно идиотская библиотека, это просто facepalm
Асинхронности нет, обработка ошибок отсутствует, представлением результатов вы себя решили так же не обременять.
Интересно, задавались ли вы вопросом — зачем нужна школотронская отсебятина там, где всё давно уже решено? Впрочем, судя по выбору «xNet» анализировать информацию из интернета вы не научились
Вы представили абсолютно кривой код — грязный и не работающий. И это при том, что поставленная задача — всего лишь отправить http запросы двух видов! Например выбранный способ авторизации AuthorizationForm, WebBrowser, DocumentCompleted — дичайшее усложнение примитивнейшей задачи отправки http POST запроса с последующим разбором ответа.
В качестве средства для упрощения http клиента выбрана абсолютно идиотская библиотека, это просто facepalm
Асинхронности нет, обработка ошибок отсутствует, представлением результатов вы себя решили так же не обременять.
Интересно, задавались ли вы вопросом — зачем нужна школотронская отсебятина там, где всё давно уже решено? Впрочем, судя по выбору «xNet» анализировать информацию из интернета вы не научились
приложение не будет использовать готовые библиотеки
буду использовать две библиотеки
Вы уж определитесь, не будете использовать библиотеки или будете, это первое.
А дальше, дальше полный мрак.
- Если уж выбрали WinForms, то будьте добры разберитесь с MVC/MVP, потому что сейчас это просто мешанина из модели, бизнес-логики и работы с интерфейсом.
- Асинхронность. Работа с вебом (и с диском тоже) подразумевает асинхронность, почитайте про async/await.
- Обработка исключений. Сейчас ваше приложение будет падать от любой ошибки.
- nuget. Используемые библиотеки не надо копировать в папку с проектом, следует подключать пакеты.
- Про конвенции именования молчу.
- gitignore. В репозиторий не надо заливать результаты (dll, exe) и настройки студии. На гитхабе есть готовые примеры файлов для C# проектов.
И у меня стойкое ощущение дежавю, на хабре регулярно появляются такие вот недо-статьи с хеллоуворлдами...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с API ВКонтакте на C#