Не равнозначны. GetObjectData + конструктор это тонны обезъяньей работы и ненужного нечитаемого кода.
Как минимум требуется указывать все дважды — и в конструкторе и в GetObjectData. Если класс большой то чтобы понять сериализуется свойтсво или нет придется прокручивать в метод сериализации и смотреть что там происходит. А атрибут видно сразу. Плюс метаданные дают больше возможностей для генерации кода если это вдруг необходимо где может понадобиться информация о том что сериализуется а что нет. Плюс не надо копипастить конструкторы десериализации в наследные классы.
Ну и справедливости ради следует отметить что, если говорить о способах «из коробки», то при сериализации в общем случае атрибуты свойствам вообще указывать не обязательно, только для тех свойств которые следует игнорировать, а они есть не всегда, и Serializable самому классу (а если есть parameterless конструктор то для datacontractserializer-ов даже это необязательно, т.е. вообще ничего не нужно).
Итого, ISerializable применим только когда необходимо сделать совместимость с каким то определенным форматом или для каких то хитроумных оптимизаций. Для обычной повседневной сериализации, а это подавляющее большинство случаев, использование этого интерфейса должно заворачиваться на code review с последующей раздачей пинков людям его написавшим.
Касаемо сериализации есть еще один очень полезный совет, который скорее всего сделает неактуальными все остальные — по возможности вообще не использовать ISerializable и всякие там BinaryFormatter. В 98% случаев это излишне и DataContract-ы удобнее, а там свои особенности.
В плане использования одной базы на все тесты с нормальными рсубд MSSQL конечно в этом плане все проще — в TestInitialize создать TransactionScope, в TestCleanup вызвать Dispose на нем, и вообще не надо думать что там тестируемый код с базой делает.
У нас схожие проблемы сравнительно недавно как раз были: и с кучей кода для инициализации одних и тех же тестовых объектов в разных тестах и с тупящей инициализацией базы после того как вся эта инициализация перенеслась в один общий для всех тестов модуль. И все это еще приправлено повторными выполнениями тестов с разными данными через атрибут DataSource. Последнее сильно портило картину, т.к. атрибут DataSource требует данные из той же базы и соотв. надо ее проинициализировать до того как движок запускающий тесты туда полезет за необходимыми значениями, а это происходит до того как срабатывают всякие там TestInitialize и ClassInitialize методы, да и вообще любой код теста, пришлось шаманить.
«Все равно всё собирают в Китае», но производят для разных рынков — по-разному. Одна и та же вещь может быть сделана из схожих, но различных по качеству материалов.
Можно пруфлинков каких-н? Или просто надо нагнать на читателей страху мол «не покупайте айфоны в ближайшем салоне связи а везите через полпланеты используя наш сервис»?
Очевидно потому что он менее прибыльный. Покупка лицензии дело единовременное, а обкатанный и за долгое время отлаженный софт и рабочий процесс с ним связанный означают минимальные обращения клиента в, наверняка, платную поддержку. А так запрет использования старого софта дал бы возможность вытянуть из клиентов еще немало бабла за внедрение и поддержку новых версий и фикс собственных багов. Иными словами, компании делающие ПО на заказ сторонним заказчикам не заинтересованы чтобы у клиента было все хорошо.
Это баловство. Из нормальных решений существует peavey revalver на PC, там реально хороший звук в отличие от всяких гитарригов и прочего шлака включая не самые лучшие процы до 50тр, а возможностей, особенно при подключении как vst к какому-н sonar, больше как ни крути чем у большинства «железных» процессоров.
Я ярлыки не навешиваю, просто все это пройденные этапы и наступленные грабли.
Не вижу ничего обозримого и нормального в словарях словарей из списков массивов пар ключ-значение. Они могут быть оправданы только в случае каких то очень злых оптимизаций, и то сугубо внутри класса, который в этом случае должен отвечать только за управление этими коллекциями и следовательно быть небольшим. В этом случае никакого мощного редактирования или многократного повторения возникнуть не может — в классе будет 1+ полей с таким типом и все, локальные переменные используют var все просто и понятно, никаких typedef не нужно.
Если при замене int на uint или объект в одном словаре идет какое то _мощное_ редактирование то скорее всего связность кода слишком высокая и/или еще что то в этом роде. И тут опять же надо упрощать и рефакторить а не костылить синтаксический сахар.
Если в одном и том же классе один используется напрямую некий Document из разных сторонних библиотек, то с немалой вероятностью
этот класс — «божественный объект», который к тому же не покрыт нормально тестами по причине невозможности подмены этих сторонних объектов. Обычно за работу с одной библиотекой отвечает одно, за работу с другой — второе, за взаимодействие прослоек — третье.
Ну и если уж без коллизий или многократно используемых сложных имен типов совсем никуда то ограничения директивы using одним файлом скорее преимущество чем недостаток — чтобы эта зараза гарантированно автоматически не распространялась на полпроекта.
Ну на самом деле пользы от этого никакой, т.к. указатель можно скастовать к IntPtr и таки передать через params.
На практике вроде бы единственное реальное применение __arglist — это p/invoke вызовы всяких там printf.
Немаловажное отличие __arglist от params — в него можно передавать unsafe указатели, а затем доставать их через __refvalue. Указатель нельзя скастовать ни к object ни к dynamic.
Вложенные дженерики это за редким исключением быдлокод. Если у вас конфликтуют пространства имен — это быдлокод. Если у вас over9000 параметров в дженерике — это быдлокод.
Typedef его конечно мог бы замаскировать, но быдлокодом быть от этого он не перестанет.
А для локалных переменных имя типа читать не нужно, поскольку что за объект обычно понятно из его имени и того чем инициализируют переменную. А если непонятно (т.е. имена переменных вроде a, b, c и ниочем не говорящие названия методов), то это опять же быдлокод, т.о. var сделает неудобочитаемым только изначально неудобочитаемый код, а нормальный код становится только чище и проще.
Насчет var — дело привычки. Обычно отторжение такой синтаксис вызывает только у тех кто долгое время писал на С/С++, со временем привыкают. Читаемость это нисколько не ухудшает если код написан нормально.
И вот 100% не надо typedef, вреда от него будет больше чем пользы. Если имя типа получается слишком сложным то проблема решается вовсе не синтаксическими костылями. Переименуйте тип, создайте новый итд итп. И не используйте вложенные generic-и где ни попадя, и проблемы не будет.
Если же вам нужен просто интерфейс который можно динамически строить на каком-то декларативном языке, так тот же XAML, XUL, QML
Ну для .NET из коробки только XAML. Все остальное с костылями и следовательно заранее неизвестным количеством граблей на которые придется наступить. В этом плане на фоне прочих 'неродных' решений HTML пожалуй будет предсказуемее что ли. А так, теоретически, к примеру при наличии в проекте веб-частей, возможно использование суммарно на одну технологию меньше перекрыло бы 'не лучшесть' этого варианта.
Но в любом случае я согласен что что-либо серьезное пока только на сторонних движках можно делать, ибо всегда чем меньше приложение зависит от внешних факторов тем лучше.
Вы либо абсолютно не знаете что такое WPF Browser Applicaiton либо не поняли идею статьи.
WPF Browser Applicaiton не заворачивается в html, такое приложение загружается браузером и запускается в отдельном процессе PresentationHost.exe, просто parent-окном является браузер. На такой «странице» с этим xbap-приложением HTML отсутствует в принципе.
То что вы советуете диаметрально противоположно сути статьи. Суть — рисовать UI десктопного приложения на HTML _вместо_ XAML или WinForms, и встраивать в приложение браузер для его отрисовки. Подчеркну — десктопное приложение, с полными возможностями десктопных приложений и без неободимости использовать к-л сервера. Вы же советуете взять «десктопное» приложение с десктопной технологией UI (xaml ни в какой html при выполнении не трансформируется) и запихнуть его тем самым в браузер, причем непонятно зачем, поскольку никаких преимуществ по сравнению с обычным wpf приложением при использовании в качестве standalone-приложения это не даст, зато на ровном месте получаем кучу ограничений песочницы в которой оно выполняется и которые еще руками отключать придется.
Да, я читал об этом. Но считаю что по возможности лучше обходиться без записей в чужие/системные ключи реестра когда это возможно. Раз тег тоже решает проблему, то реестр можно не трогать. Но ключ реестра поможет при отображении не собственного текста из памяти а какой-то реальной веб-страницы из интернета, на содержимое которой повлиять невозможно.
Как минимум требуется указывать все дважды — и в конструкторе и в GetObjectData. Если класс большой то чтобы понять сериализуется свойтсво или нет придется прокручивать в метод сериализации и смотреть что там происходит. А атрибут видно сразу. Плюс метаданные дают больше возможностей для генерации кода если это вдруг необходимо где может понадобиться информация о том что сериализуется а что нет. Плюс не надо копипастить конструкторы десериализации в наследные классы.
Ну и справедливости ради следует отметить что, если говорить о способах «из коробки», то при сериализации в общем случае атрибуты свойствам вообще указывать не обязательно, только для тех свойств которые следует игнорировать, а они есть не всегда, и Serializable самому классу (а если есть parameterless конструктор то для datacontractserializer-ов даже это необязательно, т.е. вообще ничего не нужно).
Итого, ISerializable применим только когда необходимо сделать совместимость с каким то определенным форматом или для каких то хитроумных оптимизаций. Для обычной повседневной сериализации, а это подавляющее большинство случаев, использование этого интерфейса должно заворачиваться на code review с последующей раздачей пинков людям его написавшим.
нормальными рсубдMSSQL конечно в этом плане все проще — в TestInitialize создать TransactionScope, в TestCleanup вызвать Dispose на нем, и вообще не надо думать что там тестируемый код с базой делает.У нас схожие проблемы сравнительно недавно как раз были: и с кучей кода для инициализации одних и тех же тестовых объектов в разных тестах и с тупящей инициализацией базы после того как вся эта инициализация перенеслась в один общий для всех тестов модуль. И все это еще приправлено повторными выполнениями тестов с разными данными через атрибут DataSource. Последнее сильно портило картину, т.к. атрибут DataSource требует данные из той же базы и соотв. надо ее проинициализировать до того как движок запускающий тесты туда полезет за необходимыми значениями, а это происходит до того как срабатывают всякие там TestInitialize и ClassInitialize методы, да и вообще любой код теста, пришлось шаманить.
По сравнению с ssd разницы на глаз не видно — все в CPU упирается.
Можно пруфлинков каких-н? Или просто надо нагнать на читателей страху мол «не покупайте айфоны в ближайшем салоне связи а везите через полпланеты используя наш сервис»?
Не вижу ничего обозримого и нормального в словарях словарей из списков массивов пар ключ-значение. Они могут быть оправданы только в случае каких то очень злых оптимизаций, и то сугубо внутри класса, который в этом случае должен отвечать только за управление этими коллекциями и следовательно быть небольшим. В этом случае никакого мощного редактирования или многократного повторения возникнуть не может — в классе будет 1+ полей с таким типом и все, локальные переменные используют var все просто и понятно, никаких typedef не нужно.
Если при замене int на uint или объект в одном словаре идет какое то _мощное_ редактирование то скорее всего связность кода слишком высокая и/или еще что то в этом роде. И тут опять же надо упрощать и рефакторить а не костылить синтаксический сахар.
Если в одном и том же классе один используется напрямую некий Document из разных сторонних библиотек, то с немалой вероятностью
этот класс — «божественный объект», который к тому же не покрыт нормально тестами по причине невозможности подмены этих сторонних объектов. Обычно за работу с одной библиотекой отвечает одно, за работу с другой — второе, за взаимодействие прослоек — третье.
Ну и если уж без коллизий или многократно используемых сложных имен типов совсем никуда то ограничения директивы using одним файлом скорее преимущество чем недостаток — чтобы эта зараза гарантированно автоматически не распространялась на полпроекта.
На практике вроде бы единственное реальное применение __arglist — это p/invoke вызовы всяких там printf.
Typedef его конечно мог бы замаскировать, но быдлокодом быть от этого он не перестанет.
А для локалных переменных имя типа читать не нужно, поскольку что за объект обычно понятно из его имени и того чем инициализируют переменную. А если непонятно (т.е. имена переменных вроде a, b, c и ниочем не говорящие названия методов), то это опять же быдлокод, т.о. var сделает неудобочитаемым только изначально неудобочитаемый код, а нормальный код становится только чище и проще.
И вот 100% не надо typedef, вреда от него будет больше чем пользы. Если имя типа получается слишком сложным то проблема решается вовсе не синтаксическими костылями. Переименуйте тип, создайте новый итд итп. И не используйте вложенные generic-и где ни попадя, и проблемы не будет.
Anonymous types незаменимы в linq например.
Ну для .NET из коробки только XAML. Все остальное с костылями и следовательно заранее неизвестным количеством граблей на которые придется наступить. В этом плане на фоне прочих 'неродных' решений HTML пожалуй будет предсказуемее что ли. А так, теоретически, к примеру при наличии в проекте веб-частей, возможно использование суммарно на одну технологию меньше перекрыло бы 'не лучшесть' этого варианта.
Но в любом случае я согласен что что-либо серьезное пока только на сторонних движках можно делать, ибо всегда чем меньше приложение зависит от внешних факторов тем лучше.
WPF Browser Applicaiton не заворачивается в html, такое приложение загружается браузером и запускается в отдельном процессе PresentationHost.exe, просто parent-окном является браузер. На такой «странице» с этим xbap-приложением HTML отсутствует в принципе.
То что вы советуете диаметрально противоположно сути статьи. Суть — рисовать UI десктопного приложения на HTML _вместо_ XAML или WinForms, и встраивать в приложение браузер для его отрисовки. Подчеркну — десктопное приложение, с полными возможностями десктопных приложений и без неободимости использовать к-л сервера. Вы же советуете взять «десктопное» приложение с десктопной технологией UI (xaml ни в какой html при выполнении не трансформируется) и запихнуть его тем самым в браузер, причем непонятно зачем, поскольку никаких преимуществ по сравнению с обычным wpf приложением при использовании в качестве standalone-приложения это не даст, зато на ровном месте получаем кучу ограничений песочницы в которой оно выполняется и которые еще руками отключать придется.