Спасибо за отличную подборку. Если позволите добавлю свои 5 копеек. Есть отличные ребята из JUG.ru / CodeFreeze которые помимо встреч JUG и CodeFreeze делают еще ряд крутых технических конференций:
MulticastDelegate никогда не вызывает подписчика после того как он отписан.
Каждый раз как вы подписываетесь на событие (event) или отписываетесь от него создается новый MulticastDelegate. По этому и создается впечатление что он вызывает подписчика после отписки, но это не так. Вообще MulticastDelegate по использованию — imutable. По этому в приведенном примере (где MulticastDelegate перед вызовом копируется в локальную переменную) все работает корректно, но не так как вы ожидали.
На счет того что код хороший — не могли бы вы привести пример где такой подход (когда подписчики события должны знать что-либо друг о друге) является хорошим кодом. У меня в голову ни один пример не приходит.
Случай когда подписчик отписывает себя сам — предлагать не надо, он бывает полезный, но к рассматриваемой проблеме никак не относится.
Можно — но никто не гарантирует какой event handler будет вызван первым.
Если вам это не важно, то не понятно зачем вам 2 event handler. Все можно сделать и одним. И код получится намного чище.
Mutual exclusive event handlers — такая штука не поддерживается Multicast Delegate и я не могу найти не одного примера где это действительно полезно.
Этот пример не валиден тк MulticastDelegate не гарантирует порядок исполнения. Даже в «хорошем» случае (когда по идее все должно падать на NPR) сначала может быть вызван B а только потом A.
Так проблема в том что гугл приходит к производителю телефона и говорит — либо у тебя все устройства с GMS либо без — выбирай. На сколько я понял из поста Бобука.
Имхо это очень не технологическая и не здоровая конкуренция. Яндекс именно против этого факта выступает.
Нет — вопрос профессионализма дизайна — это удобство тех интерфейсов которые он дизайнит — это все. Дизайнер не должен понимать что 2 лишних бордера в коллекции элементов, где смена элементов происходит часто — это проблема производительности. Это задача разработчика. И отвечает за это разработчик. И то что приложение может расползтись при разных DPI в системе — тоже забота разработчика. К дизайнеру это не имеет никакого отношения.
>В моём примере ширина бордера является 1/30 высоты ячейки, но в какой-то момент дизайнер может захотеть изменить это значение, и в этом случае ему придётся идти к программисту или самому лезть в код модели.
>Конечно, концепция разделения зон ответственности дизайнеров и программистов с треском провалилась (по крайней мере, я не знаю ни одного живого примера), но к этому следует стремиться.
А зачем? Это не работает. Больше того — отдать xaml дизайнеру это получить либо проблемы в производительности, либо проблемы с разъезжающимся UI. ИМХО — с этим надо просто смирится и жить дальше. Уже сделали что дизайнер может разговаривать с разработчиком на одном языке (xaml), но допускать любого кроме разработчика к мастер ветке — это верный путь к багам.
>View-Model должна содержать данные для отображения
ИМХО но данным место в модели. Если у нас хранится высота колонки во вью модели, то и ширину ее бордера имеет смысл хранить и считать там-же (все в одном месте как минимум). View-Model это модель вьюшки и вся кастомная логика вью должна быть там.
Конвертор как раз сопровождать просто (зафиксировать функциональность и написать тесты) так-же как и view-model. Сложно сопровождать xaml — а именно код в нем написанный.
Проблема в том что вы часть кода переносите в xaml — имхо порочная практика.
> а использование свойств для этих целей во вьюмодели загромождают её.
Имхо — нет. Ответственность view-model — это содержать логику работы view. Запрос веб странички — загромождает view-model, а вот как для этого ui-элемента конвертировать состояние в визуальное представление — нет.
Опять — же все сказанное ИМХО, наработанное за несколько лет ведения и развития нескольких длинных проектов на WPF (все проекты живут уже по 2-3 года и активно развивались без переписывания с нуля)
а просто показывать Thickness из view-model чем вам не нравится?
Как плюс — явная прозрачность алгоритма получения, отличная тестируемость (никакой разработчик вам никогда не сломает ваш алгоритм), возможность пробежать по крайним случаям (а что будет если например ViewModel.RowHeight = 0 ?).
Конвертор — это будет отдельный класс — согласен что для простой математической операции — оверкил, но при этом его тоже на порядок легче сопровождать.
ИМХО — xaml и так очень сложно читаемый язык программирования. Вынося в него логику — вы усложняете себе жизнь в дальнейшем.
Вы чемпион в дисциплине — «Что мне сделать чтобы не писать легко читаемый и трестируемый код во вью модели?»
В техническом плане — то что вы сделали — просто супер. Но я бы никогда не стал использовать это в продакшене. Все приведенный use-case намного проще (более читаемо и проще для тестирования) имплементировать на уровне view-model.
Но повторюсь — с технической точки зрения — просто прекрасно.
Дима вам мягко намекает что Arbitrage — это биржевой прием игры на разнице в стоимости активов на разных биржах.
Вы наверное имели ввиду Arbitration — что как раз и есть привлечение арбитра для решения споров между сторонами сделки.
Java — очень простой язык с очень сложной экосистемой. Я бы как раз начинал учить народ именно Java, только заменив JDK чем-то менее разухабистым. Ну или заставляя студентов реализовывать большинство применяемых классов.
>А еще java.util.Date, java.util.Calendar. Вы правда думаете, что нужно так много классов?
Ок давайте поговорим о System.Collection — которые явный костыль для совместимости с 1.0. Или 2 API для работы с XML.
>Норм, C# и .NET хорошо спроектированы. В стандартной библиотеке никак, она спроектирована с учетом того, чтобы предоставить удобное API. В итоге везде можно передавать DateTime и не медитировать над тем чтобы конвертировать дату из одного класса в другой. Если мы хотим конвертировать в unixtime и обратно (правда, не очень сложный алгоритм), то можно написать extension метод для DateTime, который в коде будет выглядеть родным методом над DateTime. А, ну да, можно установить nuget package, который дает эту возможность.
Бла-Бла-Бла — вам это не нужно, а если нужно, то просто самому написать, а если сложно самому написать у нас есть менеджер зависимостей. Вот это да, вот это я понимаю ответ! Не несите такого пожалуйста. У .Net в стандартной библиотеки есть очень хорошо написанные куски — но есть моменты где стандартного функционала явно не хватает.
> Зачем сервису эти фреймворки-то?
Оо — как зачем. А весь life-time management мне самому писать? Или разбор конфигурации в 21м веке?
> Вот я пишу веб-приложение на ASP.NET MVC + Web API. Зачем сервису эти фреймворки-то? Доступ к системе роутинга и движку рендеринга?
Не зачем — я их не подключу в бекэнд задаче
>Ну дык, это решается подключением парочки библиотек.
Да вы сделаете так — потом будем думать как сделать в winsdor lifetime scope на wcf — сессию по мультеплексированному коннекшенну, ну или создавать дерево классов руками приковывая зависимости
>Меня покоробило сравнение c Servlet API + JSP. Валидации данных нет, биндинга моделей нету, security нету, к населена роботами.
Ну я тоже признал что сравнение не корректное 2 комментариями выше.
>И почему вы думаете, что весь стек .NET это сырой, неясный и противоречивый продукт-то?
Ну где я это написал? .Net стек я люблю — у меня блин 9 лет опыта разработки на нем. Я прекрасно его знаю и знаю какие проблемы возникают при попытках скрестить разные библиотеки. Spring пытается решить эти проблемы. В .Net ему к сожалению аналогов нет. Может и не нужно — тк задача у него в generic виде дать вам ужа-ежа. В Java тоже много веселого. Попробуйте скрестить Guice и Netty, так чтобы на каждый channel создавался свой scope — найдете кучу увлекательного времяпрепровождения. Задача которую решает Spring очень сложная — создать среду где вы пишите минимум кода и все инструменты у вас под рукой и интегрированы в эту среду. Пока на .Net необходимости в такой среде нет. Но на Java жить без нее уже сложно.
>Кстати, у вас там уже определись какой класс должен использоваться для работы с временем и датой?
А вам с какой с таймзон офсетом или без него? LocalDateTime, ZonedDateTime, Instant и еще много других.
А как там в вашей стандартной библиотеки можно unix timestamp в объект времени и даты перевести?
>Unity умеет AOP в runtime, Windsor умеет AOP в runtime (с этим работал), Fody предоставляет самые примитивные возможности code rewriting (в compile-time; работал с этим), LinFu предоставляет AOP в compile time, PostSharp (вот он правда платный) предоставляет AOP в compile time.
Ага, вот Spring c помощью AspectJ умеет это делать в одном месте и сам — без попытки скрестить ежа с ужом в вашем коде.
>Ну да. Если хотите создавать десктопные приложения есть WPF. Если кто-то думает, что можно эффективно писать десктопные, мобильные и веб-приложения на одном фреймворке, то мне кажется, что он упоролся и не понимает, что конечно же можно. Но цена этого…
Воу воу — у нас только 2 типа приложений есть? Есть например сервисы обрабатывающие данные в бекэнде и их тоже можно писать с помощью Spring.
>Внутри springа все побито на модули, только походу вы этого не видите и не понимаете.
Да нет — прекрасно вижу и понимаю. Заслуга Spring в том что создатели скрестили в нормальном виде кучу библиотек и отдали нам готовый, ясный и непротиворечивый продукт, в котором есть решение для практически любой часто повторяющейся проблемы.
В .NET мире все по другому — я не спорю. Разные подходы.
Но если вы обратите внимание на начало этой ветки то вы увидите что было сравнение Spring c ASP.Net, я же в резкой и саркастической форме указал на то, что сравнение не корректно.
Я не говорю про стандартную библиотеку .NET (и ее бы сравнивать с Java SE) а именно о ASP.NET. Поверьте — я очень хорошо разбираюсь в .NET мире. Знаю например и о Autofac (а может Unity или NInject), NHibernate и Entity Framework. Наверное я немного сгустил краски, но ASP.NET это набор библиотек для создания web — приложений. Spring — это фреймворк для создания любых приложений и в нем намного больше всего. Как минимум поддержка работы с базами данных (Templates, Transactions) и поддержка AOP. Ну и мессаджинг.
Возможность есть — это факт :) мы вроде именно о ней говорили :)
А вообще имхо — Unsafe не на много более сложный, но намного более явный чем приведенный код, в рамках парадигмы managed среды.
.NEXT:
Видео: www.youtube.com/playlist?list=PLtWrKx3nUGBeCTpN--0BsxxM0dFPVMXip
сайт: dotnext.ru
JPoint: www.youtube.com/playlist?list=PLVe-2wcL84b8qDFSA2rpbpuE3OTkEbAwe
сайт: javapoint.ru
Mobius: www.youtube.com/channel/UCG70q1HRspLdd93HW94WS-A/videos
сайт: mobiusconf.com
Ну и собственно:
JUG.ru: www.youtube.com/user/JUGRuVideo
CodeFreeze: www.youtube.com/user/CodeFreezeRU
Каждый раз как вы подписываетесь на событие (event) или отписываетесь от него создается новый MulticastDelegate. По этому и создается впечатление что он вызывает подписчика после отписки, но это не так. Вообще MulticastDelegate по использованию — imutable. По этому в приведенном примере (где MulticastDelegate перед вызовом копируется в локальную переменную) все работает корректно, но не так как вы ожидали.
На счет того что код хороший — не могли бы вы привести пример где такой подход (когда подписчики события должны знать что-либо друг о друге) является хорошим кодом. У меня в голову ни один пример не приходит.
Случай когда подписчик отписывает себя сам — предлагать не надо, он бывает полезный, но к рассматриваемой проблеме никак не относится.
Если вам это не важно, то не понятно зачем вам 2 event handler. Все можно сделать и одним. И код получится намного чище.
Mutual exclusive event handlers — такая штука не поддерживается Multicast Delegate и я не могу найти не одного примера где это действительно полезно.
Имхо это очень не технологическая и не здоровая конкуренция. Яндекс именно против этого факта выступает.
>Конечно, концепция разделения зон ответственности дизайнеров и программистов с треском провалилась (по крайней мере, я не знаю ни одного живого примера), но к этому следует стремиться.
А зачем? Это не работает. Больше того — отдать xaml дизайнеру это получить либо проблемы в производительности, либо проблемы с разъезжающимся UI. ИМХО — с этим надо просто смирится и жить дальше. Уже сделали что дизайнер может разговаривать с разработчиком на одном языке (xaml), но допускать любого кроме разработчика к мастер ветке — это верный путь к багам.
>View-Model должна содержать данные для отображения
ИМХО но данным место в модели. Если у нас хранится высота колонки во вью модели, то и ширину ее бордера имеет смысл хранить и считать там-же (все в одном месте как минимум). View-Model это модель вьюшки и вся кастомная логика вью должна быть там.
Проблема в том что вы часть кода переносите в xaml — имхо порочная практика.
> а использование свойств для этих целей во вьюмодели загромождают её.
Имхо — нет. Ответственность view-model — это содержать логику работы view. Запрос веб странички — загромождает view-model, а вот как для этого ui-элемента конвертировать состояние в визуальное представление — нет.
Опять — же все сказанное ИМХО, наработанное за несколько лет ведения и развития нескольких длинных проектов на WPF (все проекты живут уже по 2-3 года и активно развивались без переписывания с нуля)
Как плюс — явная прозрачность алгоритма получения, отличная тестируемость (никакой разработчик вам никогда не сломает ваш алгоритм), возможность пробежать по крайним случаям (а что будет если например ViewModel.RowHeight = 0 ?).
Конвертор — это будет отдельный класс — согласен что для простой математической операции — оверкил, но при этом его тоже на порядок легче сопровождать.
ИМХО — xaml и так очень сложно читаемый язык программирования. Вынося в него логику — вы усложняете себе жизнь в дальнейшем.
В техническом плане — то что вы сделали — просто супер. Но я бы никогда не стал использовать это в продакшене. Все приведенный use-case намного проще (более читаемо и проще для тестирования) имплементировать на уровне view-model.
Но повторюсь — с технической точки зрения — просто прекрасно.
Вы наверное имели ввиду Arbitration — что как раз и есть привлечение арбитра для решения споров между сторонами сделки.
Ок давайте поговорим о System.Collection — которые явный костыль для совместимости с 1.0. Или 2 API для работы с XML.
>Норм, C# и .NET хорошо спроектированы. В стандартной библиотеке никак, она спроектирована с учетом того, чтобы предоставить удобное API. В итоге везде можно передавать DateTime и не медитировать над тем чтобы конвертировать дату из одного класса в другой. Если мы хотим конвертировать в unixtime и обратно (правда, не очень сложный алгоритм), то можно написать extension метод для DateTime, который в коде будет выглядеть родным методом над DateTime. А, ну да, можно установить nuget package, который дает эту возможность.
Бла-Бла-Бла — вам это не нужно, а если нужно, то просто самому написать, а если сложно самому написать у нас есть менеджер зависимостей. Вот это да, вот это я понимаю ответ! Не несите такого пожалуйста. У .Net в стандартной библиотеки есть очень хорошо написанные куски — но есть моменты где стандартного функционала явно не хватает.
> Зачем сервису эти фреймворки-то?
Оо — как зачем. А весь life-time management мне самому писать? Или разбор конфигурации в 21м веке?
> Вот я пишу веб-приложение на ASP.NET MVC + Web API. Зачем сервису эти фреймворки-то? Доступ к системе роутинга и движку рендеринга?
Не зачем — я их не подключу в бекэнд задаче
>Ну дык, это решается подключением парочки библиотек.
Да вы сделаете так — потом будем думать как сделать в winsdor lifetime scope на wcf — сессию по мультеплексированному коннекшенну, ну или создавать дерево классов руками приковывая зависимости
>Меня покоробило сравнение c Servlet API + JSP. Валидации данных нет, биндинга моделей нету, security нету, к населена роботами.
Ну я тоже признал что сравнение не корректное 2 комментариями выше.
>И почему вы думаете, что весь стек .NET это сырой, неясный и противоречивый продукт-то?
Ну где я это написал? .Net стек я люблю — у меня блин 9 лет опыта разработки на нем. Я прекрасно его знаю и знаю какие проблемы возникают при попытках скрестить разные библиотеки. Spring пытается решить эти проблемы. В .Net ему к сожалению аналогов нет. Может и не нужно — тк задача у него в generic виде дать вам ужа-ежа. В Java тоже много веселого. Попробуйте скрестить Guice и Netty, так чтобы на каждый channel создавался свой scope — найдете кучу увлекательного времяпрепровождения. Задача которую решает Spring очень сложная — создать среду где вы пишите минимум кода и все инструменты у вас под рукой и интегрированы в эту среду. Пока на .Net необходимости в такой среде нет. Но на Java жить без нее уже сложно.
А вам с какой с таймзон офсетом или без него? LocalDateTime, ZonedDateTime, Instant и еще много других.
А как там в вашей стандартной библиотеки можно unix timestamp в объект времени и даты перевести?
>Unity умеет AOP в runtime, Windsor умеет AOP в runtime (с этим работал), Fody предоставляет самые примитивные возможности code rewriting (в compile-time; работал с этим), LinFu предоставляет AOP в compile time, PostSharp (вот он правда платный) предоставляет AOP в compile time.
Ага, вот Spring c помощью AspectJ умеет это делать в одном месте и сам — без попытки скрестить ежа с ужом в вашем коде.
>Ну да. Если хотите создавать десктопные приложения есть WPF. Если кто-то думает, что можно эффективно писать десктопные, мобильные и веб-приложения на одном фреймворке, то мне кажется, что он упоролся и не понимает, что конечно же можно. Но цена этого…
Воу воу — у нас только 2 типа приложений есть? Есть например сервисы обрабатывающие данные в бекэнде и их тоже можно писать с помощью Spring.
>Внутри springа все побито на модули, только походу вы этого не видите и не понимаете.
Да нет — прекрасно вижу и понимаю. Заслуга Spring в том что создатели скрестили в нормальном виде кучу библиотек и отдали нам готовый, ясный и непротиворечивый продукт, в котором есть решение для практически любой часто повторяющейся проблемы.
В .NET мире все по другому — я не спорю. Разные подходы.
Но если вы обратите внимание на начало этой ветки то вы увидите что было сравнение Spring c ASP.Net, я же в резкой и саркастической форме указал на то, что сравнение не корректно.
А вообще имхо — Unsafe не на много более сложный, но намного более явный чем приведенный код, в рамках парадигмы managed среды.