Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Технологии Microsoft на которых можно предоставлять решения

11 комментариев

Многие разработчики так или иначе застревают в определенной “нише” в плане того, с чем они имеют дело. Например, разработчики Asp.Net фокусируются на таких вещах как jQuery и AJAX. Если разработчик долго работает в одной области, то он скорее всего (я по себе говорю) не особо знает, для чего нужны остальные технологии в стеке. А в случае с Microsoft, стек весьма большой. Поэтому я решил написать достаточно высокоуровневый пост на тему того, какие вообще направления разработки существуют для дотнетчиков.

Windows Forms (WinForms)

Ни одна технология для создания обычных desktop-приложений не зарекомендовала себя так хорошо как WinForms. Я это вполне серьезно – посмотрите на рынок, на чем приложения писались до WinForms. Конечно, поддержка есть много где – оконные приложения легко делать в Delphi, их можно делать в Java (сначала был AWT, потом Swing), до .Net-а был MFC, также есть подходы вроде Qt (произносится кстати как ‘cute’ а не ‘queue tee’). Но WinForms для оконных приложений просто рулит.

Причина рулезности многогранна. Во-первых, все важные контролы для forms доступны из коробки, чего нельзя было сказать про тот же WPF. Помимо этого, forms сейчас – зрелый фреймворк. Для него написано очень много действительно классных компонентных библиотек – как платных (к пр. DevExpress) так и бесплатных (например Krypton Toolkit).

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

Windows Presentation Foundation (WPF)

Этой технологии не так повезло. Во-первых, WPF вышел без множества действительно нужных контролов. Помнится в свое время нужно было устанавливать компоненты (слава богу бесплатные) компании Xceed которые, кстати, наверняка неплохо “проехались” на слабости WPF. Тем не менее, отсутствие контролов (таких как календарь или таблица) сейчас поправлено было не единственной проблемой.

Второй проблемой было (и пока что остается, но ненадолго) ужасное отрисовывание шрифтов в WPF. Проблема проста – Microsoft использовало ущербный алгоритм вместо хорошего. Причины неизвестны, но мне это стоило немало нервов – ведь я в свое время написал программу на WPF и разворачивал ее у клиента на машинах с Windows XP. На момент написания этого поста, проблема еще не решена – ведь у пользователей все еще .Net 3.5, и когда они обновятся до .Net 4 зависит, вообщем-то, от нас разработиков.

Несмотря на ряд минусов, WPF имеет огромный плюс – это более грамотно продуманная архитектура. Например, привязывание данных в WinForms – это жутко нестабильная практика, которая ведет себя хаотично вплоть до разного поведения на разных машинах. В WPF привязывание данных реализовано на ура, и поддерживается даже в особенно сложных случаях – например, когда нужно делать привязку на статики. Это не всегда выглядит красиво, но по крайней мере это безотказно работает.

И приемущество не только в data binding – многие аспекты WPF как системы презентации данных (а мы сейчас говорим про enterprise-приложения, а не про игры) продуманы с точки зрения паттернов. В основе лежит, естественно, паттерн MVVM, но если пройтись по GoF’овским паттернам, то вы найдете много применений в инфраструктуре WPF.

В WPF много плюсов и минусов. Несмотря на это, бизнес как таковой пока что относится к WPF с опаской. Вы можете назвать какие-нибудь крупные приложения, написанные на WPF? Ну вроде как есть AutoCad, но мне, как разработчику, больше ничего на ум не приходит. Разве что всякие программистские утилиты вроде NHProf или NCover.

Silverlight

Рано или поздно это должно было случиться – Microsoft использовал WPF как базу для RIA-технологии которая призвана конкурировать с Flash. На данный момент, Silverlight установлен более чем у половины всех пользователей в сети (согласно riastats), и эта доля продолжает расти. SL идет семимильными шагами, что не всегда хорошо отражается на процессе разработки – иногда приходится иметь дело с недоработанностью API. Также, в мое практике встречались проблемы с несоответствием работы Silverlight в разныз браузерах на разных операционных системах (например Windows vs. Mac OS).

Silverlight постепенно обрастает инфраструктурой – начиная от .Net RIA Services и заканчивая сторонними UI-библиотеками. Но в процессе развития этой технологии, у него появился серьезный конкурент – jQuery UI, который позволяет делать очень богатые интерфейсы не используя RIA вообще. Хотя эти технологии и не из одной области, на данный момент в моей практике большинство “богатого” интерфейса реализуется именно используя связку HTML+CSS+JavaScript(jQuery) а также коммерческие реализации контролов.

Asp.Net (WebForms, MVC)

Давайте начистоту: веб-разработка под Asp.Net до появления MVC особо большого места на рынке не занимало. Я помню как меня бесила ситуация, когда некоторые контролы WebForms (это была версия 1.1, вроде бы) неправильно отражались в определенных браузерах. Да, на WebForms можно было работать, но это не было технологией номер 1 для сайтов. С приходом MVC ситуация поменялась – было создано столько обсуждений и дискуссий вокруг “правильного веб-фреймворка от Microsoft” что со временем MVC стал, в каком-то смысле, равноправной технологией. Сейчас люди использут его, причем используют с удовольствием. Сайты вроде StackOverflow делают этому фреймворку хорошее имя.

Следует заметить, что веб-разработка очень сильно завязана не только на программистов, но также “креативные профессии”. Ведь кто-то должен делать верстку сайта, правильно подбирать шрифты и графику, описывать сценарии взаимодействия, и так далее. Это конечно не всегда так – в моей практике очень много enterprise web-приложений были написаны на уровне “чтобы работало”, а если в них и появлялись красивости, то только за счет автоматического использования соответствующих UI-фреймворков, таких например как Telerik MVC. Кстати, использование таких фреймворков – это как раз “дискриминирующий фактор” в конкуренции с другими фирмами – поэтому я такой большой фанат платных компонентов.

SQL Server vs…

Несмотря на то, что база данных номер 1 для .Net-разработчика это конечно SQL Server, на деле встречается львиная доля приложений где DB-движок это либо Oracle либо MySQL. С этим ничего не поделать – нужно просто подстраиваться и медленно, по мере возможноси, наращивать компетенции. Тем не менее, два движка SQL которые бесплатно доступны от Microsoft (это я про SQL Server Express и SQL Server Compact Edition) прекрасно справляются с задачей хранения данных. В тандеме с дот-нетом, студией и Ado.Net, с SQL Server работать намного легче чем с другими SQL-ориентированными RDBMS.

У меня есть мнение, что поскольку SQL Server это супермощная платформа, для нее должны быть отдельные разработчики – те, кого называют Database Administrator (DBA). Идея о том что обычный дотнетчик может работать с базой данных работает ровно до того момента, когда у вас вдруг появится какая-то действительно сложная задача. По крайней мере, я не верю в то, что классный разработчик – это еще и классный DBA. Кто-то может не согласиться.

Microsoft Office

Разработка для Microsoft Office мне кажется одним из лучших способов провести время. Программная модель “офиса” понятна, и начать разрабатывать для Office можно интуитивно, не читая никаких книг. Например, создавать слайды для презентаций PowerPoint программно очень легко, и я писал об этом. Офис часто используется как вспомогательная инфраструктура для отчетов, поэтому полезным навыком считаю умение генерировать Word-документы из баз данных. В принципе, это не так сложно (если конечно вам не нужно иметь дело с такими проблемами как склонение фамилий).

SharePoint

Я пожалуй первый признаю что мои компетенции в “шарике” весьма ограничены. Тем не менее, SharePoint это одна из самых прибыльных технологий для Microsoft, поэтому неудивительно что многие компании (включая мою) хотят наращивать компетенции в этой области.

Разработка для SharePoint – это отдельная, весьма специфичная область, со своей терминологией, подходами и практиками (и даже своим аналогом StackOverflow). SharePoint базируется на WebForms, и разработка для него соответственно тоже использует эту технологию. Работа с SharePoint – это по сути дела работа с конкретной CMS, но то же самое можно сказать и про другие enterprise-платформы от Microsoft.

BizTalk

Проблема интеграции данных между разными (порой даже не гетерогенными) системами существует в весьма ограниченном кругу “ну уж очень крупных компаний”. Для таких редких целей существуют весьма редкие и дорогие технологии, такие как Microsoft BizTalk. Главная ценность программы-интегратора – это как раз наличие “адаптеров”, которые с помощью в основном визуальных средств a-la Workflow Foundation можно использовать для “вытяжки” данных из разных форматов и систем. Примечательно, что несмотря на красивые слова о том что “мы подкинули в программу адаптеров на $100k”, в BizTalk отсутствуют такие насущные адаптеры, как например адаптер для Excel или RSS. К счастью, есть добрые фирмы вроде n/Software, которые предоставляют такие адаптеры – конечно не бесплатно.

Порой клиенты хотят использования BizTalk даже когда это не очень полезно – лишь бы иметь еще одну проверенную технологию Microsoft, на которой все крутится. Например, я участвовал в биде где клиенту нужно было просто консолидировать данные из Excel-таблиц. Такая задача в принципе решается и без BizTalk, но, как говорится, “хозяин – барин”.

Microsoft Project

Project – это очень неоднозначная система управления проектами. С одной стороны, есть фирмы которые имеют достаточно большие внедрения Project’а для собственных (программистких) нужд. С другой стороны, есть огромная дельта ИТ-менеджеров которые люто ненавидят Project как “инструмент зла” и предпочитают более гибкие приложения, такие как например BaseCamp. Как бы там ни было, Project имеет свой круг поклонников. Помимо этого, по собственному опыту могу сказать что Project имеет весьма неплохую модель расширения, об использовании которой я уже писал.

Dynamics CRM

Dynamics CRM – это такая система, которую сами компании-разработчики очень активно используют для управления взаимодействием с клиентами. В этом плане платформа очень удобна – она вывешивается в интранете и интегрируется в аутлук. У нее богатый функционал для управления связями с клиентами и, конечно же, она поддается расширению через отдельный SDK.

Зачем кому-либо расширять CRM? На это масса причин, которые объясняют, почему работа с Dyn CRM вострабована на рынке. Взять например тот же портал Hoovers (как, вы не знаете что это такое?) – он предоставляет B2B площадку, которую можно интегрировать в собственный CRM (SalesForce/Dynamics/Oracle) и тем самым получать дополнительные данные по своим клиентам. Эту фичу сложно недооценить.

CRM – это пожалуй одна из технологий, которая является одновременно и способом заработка денег путем предоставления кастомных решений, и самым сердцем фирмы-разработчика – ведь без этой системы придется управлять взаимодействием с заказчиками на бумаге или в Excel’e, что конечно возможно, но только до поры до времени.

Dynamics AX и NAV

Эти две ERP системы (разного масштаба) не так востребованы в России, но это не значит что для них нельзя продавать решения на запад. Помимо отдельного языка X++, для мена разработка под эти системы – тайна покрытая мраком, в основном потому что сам я ими пока не пользуюсь (нет нужды). Но если представится возможность, мы конечно на нее прыгнем – ведь раз уж мы решили заниматься технологиями Microsoft, хорошо было бы покрыть как можно больше баз.

И все остальное…

Конечно, у Microsoft еще много интересных технологий, но все их не переслить – я лишь привел примеры тех, которые мне наиболее близки в плане предоставления решений, а тех же серверых нехнологий еще море (Commerce Server, HyperV Server, и т.д.), да и инфраструктура (например те же Directory Services) – тоже непростая область. Хотя, как все получится у меня на самом деле предсказать сложно – уж больно много “самописного” ПО производится, особенно в консалтинговой сфере. Поживем-увидим. ■

Реклама

Written by Dmitri

21 марта 2010 в 21:33

Опубликовано в asp.net, biztalk, dynamics, sharepoint, wpf

комментариев 11

Subscribe to comments with RSS.

  1. «Давайте начистоту: веб-разработка под Asp.Net до появления MVC особо большого места на рынке не занимало.»

    Что за бред? Вы откуда и куда меряете? На каком рынке не занимало? Тем более «особого места» )))

    Alexender

    21 марта 2010 at 23:42

  2. Согласен с предыдущим оратором.

    asp.net mvc — относительно юная технология, чтобы ее всерьез использовать.

    Да, а где многообещающий поставить крест на winforms, wpf, asp.net — silverlight 4?

    LexL

    22 марта 2010 at 3:35

  3. Согласен с двумя предыдущими ораторами :)

    Думаю, что у автора просто «не сложилось» с WebForms. Технология как технология: не делай перегруженных контролами страниц, и все будет хорошо. И спросом пользуется.

    MVC автор склонен переоценивать. Я только в версии 2 с появлением areas начинаю представлять как на нем сделать корпоративный портал пятью-шестью разработчиками. MVC 1 — для одиночек.

    Silverlight автор, напротив, недооценивает. jQuery прекрасно поможет в добавлении функций, но в «украсивлении» приложения это слабый помощник. А Silverlight хорош и в функциональном, и в презентативном смысле.

    ILog

    22 марта 2010 at 13:24

  4. >>Server работать намного легче чем с другими SLQ-ориентированными RDBMS.

    может SQL-ориентированными? Или что это за сокращение?

    demofoto

    23 марта 2010 at 16:15

  5. На счет того, что ASP.NET MVC 1 для одиночек это такая же чушь, как и то, что ASP.NET до MVC не использовался почти…

    К сведенью, за долго до ASP.NET MVC были и другие фреймворки: Spring.NET MVC, Castle Monorail, для примера…

    Ray

    23 марта 2010 at 21:14

    • Фреймворки были, но о них знали единицы. Это как SharpArchitecture — фреймворк есть, но мало кто он нем знает, и еще меньше тех, кто умеет правильно им пользоваться.

      Dmitri

      25 марта 2010 at 22:44

  6. > у него появился серьезный конкурент – jQuery UI,
    > который позволяет делать очень богатые интерфейсы

    jQuery UI слишком бедна функционально, чтобы быть конкурентом Silverlight. Однако более развитые javascript-фреймворки ExtJS и SmartClient (а также их GWT-ответвления) действительно позволяют строить AJAX RIA-приложения на чистом javascript.

    journeyman

    25 марта 2010 at 17:09

    • Ну, если честно, сейчас не страдаю от бедности jQuery UI, хотя де факто для веб-приложений использую комбинацию из jQuery UI, надстроек над ней в Telerik MVC, а также Telerik Asp.Net AJAX контролы.

      Dmitri

      25 марта 2010 at 22:43

      • Попробуйте заменить «комбинацию» одним цельным javascript-фреймворком из упомянутых мной, возможно жизнь станет немного проще :) Я тоже очень люблю jQuery[UI], однако им еще нужно пройти большой путь чтобы догнать более развитых собратьев и стать хоть сколько-нибудь законченной RIA-платформой, а уж тем более конкурировать с Silverlight.

        journeyman

        26 марта 2010 at 11:37

  7. Как вы думаете, почему Dynamics AX и NAV не сильно востребованны в России?

    admin@elcomrevue.ru

    31 мая 2012 at 21:28


Оставить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: