[WCF] Декларативное использование NetDataContractSerializer-а

Я уже неоднократно писал о проблемах известных типов (Known Types) в WCF и о нескольких способах ее решения. При этом я также упоминал, что одним из наиболее радикальных способов решения этой проблемы является использование сериализатора NetDataContactSerializer, вместо DataContractSerializer, используемого по умолчанию. Основное отличие первого класса от второго заключается в том, что NetDataContractSerializer сохраняет информацию о CLR-типе в сериализированный поток байтов, передаваемый между сервисом и его клиентом. Такое поведение нарушает ключевой принцип сервис-ориентированной архитектуры (SOA, Service-Oriented Architecture), который гласит о том, что сервисы и их клиенты не должны ничего знать о тех платформах, языках или технологиях, на которых они работают. Однако иногда мы можем себе позволить пойти на такие жертвы, когда четко знаем, что наша система предназначена только для платформы .Net, а другие языки и технологии использоваться не будут.

Наиболее популярным в сети способом использования NetDatacontractSerializer-а заключается в создании custom-атрибута, которым нужно пометить все методы сервиса или сам сервис целиком (этот способ я описывал в одной из предыдущих заметок и именно его я использовал на практике), однако появились сведения, что в некоторых случаях это может привести к проблемам, поскольку в этом случае производится изменение поведения (operation behavior) уже после вызова метода OpenHost, и в некоторых случаях может привести к непредсказуемому поведению. Другим, не менее важным недостатком того подхода является то, что вам нужно захардкодить ваше решение прямо в коде (путем добавления этих атрибутам к классам и/или методам) и нельзя перейти от одного решения к другому без перекомпиляции приложения. Кроме того, этот вариант не работает совместно с получением информации о сервисе посредством mex (Metadata Exchange Endpoints), поскольку в этом случае будут сгенерированы классы и интерфейсы без этого атрибута и попытка их использования ни к чему хорошему не приведет. В данном случае клиент будет использовать сериализатор DataContractSerializer, а сервис NetDataContractSerializer, и хотя данные сериализованные первым сериализатором могут быть десериализированы вторым, в обратном направлении это работает не всегда.

О вреде метода Thread.Abort

Все эти новые инструменты и технологии, которые приходят нам в помощь для повышения уровня абстракции и решения все более и более сложных задач безусловно полезны, но они иногда сами того не замечая играют с нами злые шутки.

Давайте в качестве примера рассмотрим различные сопособы прекращения работы созданного вручную потока. Если вы начали знакомство с многопоточностью, с таких чудесных библиотек как WinAPI и не менее чудесных языков программирования как С и С++, то вы наверняка очень быстро поняли, что завершать выполнение потока с помощью вызова функции TerminateThread мягко говоря не стоит. Вызов функции TerminateThread гарантировано приводит к утечкам ресурсов, памяти, некорректному состоянию объектов ядра операционной системы и еще десятку других напастей, после которых корректное состояние приложения – мало вероятно. Вызов этой функции достаточно быстро завоевал дурную славу у разработчиков (благо даже в официальной документации на эту функцию в MSDN черным по английскому сказано, что вызывать ее не стоит) и большинству разработчиков пришлось искать другие способы завершения работы потока, начиная от уведомление рабочего потока с помощью событий (events), заканчивая применением булевого флага, который проверяется рабочим потоком и устанвливается в true для его завершения.

Ретроспектива 2010 года

У каждого блоггера не зависимо от тематики, на которую он пишет, есть своя цель, ради которой он тратит свое свободное время и изливает свое сознание на страницы своего живого журнала. Для одного это может быть способом самореализации (ЧСВ оно такое ЧСВ ;) ), для второго – желание поделиться своим опытом и знаниями с другими, для третьего – систематизация уже имеющихся знаний, для четвертого – способ изучить тему поглужбе и только потом о ней рассказать другим, для пятого – повысить свою стоимость на рынке труда. Для меня каждая из этих целей играет определенную роль, но самое главное, я рассматриваю свои посты, как фотоснимки собственного сознания, на которые можно посмотреть с течением времени и увидеть себя, свой опыт и свое мышление в прошлом; понять, как я думал, чем интересовался, какие решал задачи; это такой себе способ пообщаться с самим собой в прошлом; видеопленка с собственным сознанием и профессиональным опытом. Кроме того, перечитывание своих собственных заметок позволяет значительно быстрее снова погрузиться в ту или иную тему, которая, как ни крути, в современных реалиях начинает с невероятной быстротой выветриваться из головы; не зря ведь старая китайская пословица гласит, что даже выцветшие чернила лучше хорошей памяти.

Подведение итогов прошедшего года также является хорошим способом систематизации новых знаний, полученных за это время. Не зря ведь, ретроспектива является неотъемлемой частью многих современных методик разработки, важно не просто пережить некоторые события, нужно еще и сделать из всего этого какие-то выводы. Вот и я решил подвести итоги года прошедшего, за который накопилось определенное количество материала, который не стыдно показать своим друзьям/коллегам девелоперам.