История изменений.
Версия 1.0.7.5 (текущая)
01.05.2010
1. Добавил окно «О программе»
2. Добавил иконки на кнопки.
3. Добавил возможность начала поиска по нажатию Enter в любом поле поиска
4. Исправил баг в поиске команд, при результате <2 команд ничего не отображалось
5. Добавил информативные сообщения об отсутствии результата или наличии более 100 команд

В первой части этой серии статей мы создали основу нашего приложения, в конце прошлой статьи оно показало один виджет. В этой статье мы покажем два виджета, sensing a pattern here?¹  Мы покажем два, но поместим их в разные места приложения. Мы изучим два способа сделать это, включая очень мощный механизм MEF называемый метаданные.

Если вы только перешли к этой статье вы можете взять исходные коды проекта здесь

Добавление второго виджета

Теперь когда мы получили инфраструктуру нашего приложения, добавление второго виджета должно быть легко, верно? Давайте сделаем это, на этот раз мы добавим текстовое поле.
Первым делом мы создадим новый пользовательский контрол с именем Widget2.

Далее мы перейдем в Widget2.xaml и добавим кнопку с содержимым «Hello MEF».

[cc lang="xml"]
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
d:DesignHeight="300" d:DesignWidth="400">



[/cc]

Затем перейдем в Widget2.xaml.cs и добавим наш экспорт.
[cc lang="csharp"]
using System;
using System.ComponentModel.Composition;
using System.Windows.Controls;
using System.Windows;

namespace HelloMEF
{
[Export(typeof(UserControl))]
public partial class Widget1 : UserControl
{
public Widget1()
{
InitializeComponent();
}
}
}
[/cc]

Все что мы сделали это создали новый контрол и добавили атрибут экспорта для MEF. Давайте запустим приложение.

Presto! Показался и второй виджет. Никакого редактирования app.config, никакого явного кода по регистрации. Просто добавили его в проект и все. Неплохо!

Добавление второго виджета куда нам захочется, и почему Lazy это хорошо

Выглядит очень хорошо. Но если вы читали мою первую статью, то вы помните что мы хотим показывать виджеты в разных местах потому что у нас есть две панели на экране для виджетов. Одна из них голубая, и одна желтая, но сейчас она невидимая. Так, что мы должны сделать? Один из вариантов это создать разные интерфейсы, ITopWidget, IBottomWidget. Тогда мы можем проверять класс если он реализует один из этих интерфейсов, мы поместим его в соответствующее место.

Если мы сделаем это, то наш код в MainPage будет выглядеть так:
[cc lang="csharp"]
public MainPage()
{
InitializeComponent();
PartInitializer.SatisfyImports(this);
foreach (var widget in Widgets)
{
if (widget is ITopWidget)
TopWidgets.Items.Add(widget);
else if (widget is IBottomWidget)
BottomWidgets.Items.Add(widget);
}
}
[/cc]

Это работает, однако этот способ принуждает нас создавать новые интерфейсы каждый раз когда мы захотим модернизировать пользовательский интерфейс (UI). Например, если мы захотим добавить панель с левой стороны, то мы должны создать для этого интерфейс ILeftWidget. Другой проблемой является, то что мы создаем виджеты не реализующие ни один из наших интерфейсов. И что нам с этим делать?

«Ленивая» инициализация (Lazy)

Ответ на этот вопрос – Lazy. Да друзья, это первый раз когда Lazy оказалось полезным. Если вы еще не знакомы, Lazy это новый тип в SL4 и FX4 BCL который позволяет вам отложить создание экземпляра класса. MEF полностью поддерживает Lazy, таким образом вы можете «лениво» (отложено) импортировать отдельные значения или коллекции. Для примера мы можем изменить наш атрибут ImportMany для использования Lazy, вставив следующий код в MainPage.cs:
[cc lang="csharp"]
using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;

namespace HelloMEF
{
public partial class MainPage : UserControl
{
public MainPage()
{
InitializeComponent();
PartInitializer.SatisfyImports(this);
foreach (var widget in Widgets)
{
TopWidgets.Items.Add(widget.Value);
}
}
[ImportMany]
public Lazy[] Widgets { get; set; }
}
}
[/cc]

Выше вы должны были заметить две вещи, во-первых наши виджеты теперь импортируются в массив типов Lazy, во-вторых цикл в котором мы добавляем виджеты. Value rather than the widget value directly.² Здесь вместо импорта экземпляров UserControl мы импортируем «ленивые» ссылки на наши виджеты. При первом обращении к значению, создается экземпляр UserControl к которому мы и получаем доступ к значению для добавления виджета в ItemControl TopWidget`а.

Metadata

Ну вот все хорошо, потому что сейчас мы отложили создание контролов до тех пор пока они нам не понадобятся. Недостатком этого является то что мы не знаем как определить какой из виджетов и куда мы должны его разместить. И это то место где метаданные смогут нам помочь. MEF поддерживает не только «ленивое» создание экземпляров, но он так же поддерживает концепцию экспорта метаданных. Это означает что экспорт MEF может дать дополнительную информацию о себе, которую импортер может использовать различными способами, будь то определение должен ли быть создан объект, или в нашем случае определить где он должен показываться на экране.
Импортер может получить доступ к этой информации до того как экземпляр фактически будет активирован. Это означает что если специфический экспорт не соответствует требованиям, то он не должен быть создан.

Метаданные в MEF условны, это означает что вы можете использовать их как вы считаете необходимым в соответствии с потребностями вашего приложения. Использование метаданных состоит из двух частей, первая это та в которой экспортер определяет какие метаданные будут доступны для просмотра импортеру. Затем, импортер в момент импорта может получить доступ к метаданным.

Определение метаданных для виджетов

В нашем случае мы хотим чтобы наши виджеты предоставляли нам свое положение. Для того, чтобы сделать это, мы создадим новое перечисление (enum) с именем WidgetLocation.
[cc lang="csharp"]
namespace HelloMEF
{
public enum WidgetLocation {Top, Bottom}
}
[/cc]

Затем, мы добавим метаданные Location в наши виджеты. Тут есть несколько способов сделать это с помощью MEF, самый простой из которых это начать с простого добавления атрибута ExportMetadata. Сначала перейдем в Widget1.xaml.cs и установим положение виджета сверху формы, как вы можете увидеть ниже. Предупреждение, ключ и значение могут быть произвольными, в моем случае это «Location» и «WidgetLocation.Top»
[cc lang="csharp"]
[ExportMetadata("Location", WidgetLocation.Top)]
[Export(typeof(UserControl))]
public partial class Widget1 : UserControl
{
public Widget1()
{
InitializeComponent();
}
}
[/cc]
Далее мы перейдем к Widget2 и установим его положение снизу формы.
[cc lang="csharp"]
[ExportMetadata("Location", WidgetLocation.Bottom)]
[Export(typeof(UserControl))]
public partial class Widget2 : UserControl
{
public Widget2()
{
InitializeComponent();
}
}
[/cc]
Теперь мы можем перейти к импортеру.

Предоставление доступа виджета к панели и почему у Lazy есть брат

Теперь, когда мы определили метаданные которые хотим использовать. Мы поговорили о Lazy, теперь разговор будет о его брате Lazy. В порядке предоставления нам доступа к метаданным, MEF представляет специальный класс Lazy, который может содержать метаданные. М в данном случае это интерфейс (мы назовем его представление метаданных) который содержит только методы получения свойств, где имя свойство соответствует значению ключа в метаданных. MEF автоматически создает прокси класс который реализует этот интерфейс и может содержать все метаданные. Это очень хорошо! Вы должны посмотреть на это чтобы поверить (и понять).

Так что давайте просто сделаем это, чем говорить об этом.

Первое, мы должны создать новый интерфейс с именем IWidgetMetadata который будет содержать метаданные положения (Location).

[cc lang="csharp"]
namespace HelloMEF
{
public interface IWidgetMetadata
{
public WidgetLocation Location {get;}
}
}
[/cc]

Далее мы перейдем в MainPage.xaml.cs, и изменим наш импорт виджетов что бы использовать новые метаданные. Так же, мы должны изменить логику расположения виджетов в подходящих местах.

[cc lang="csharp"]
using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;

namespace HelloMEF
{
public partial class MainPage : UserControl
{
public MainPage()
{
InitializeComponent();
PartInitializer.SatisfyImports(this);
foreach (var widget in Widgets)
{
if (widget.Metadata.Location == WidgetLocation.Top)
TopWidgets.Items.Add(widget.Value);
else if (widget.Metadata.Location == WidgetLocation.Bottom)
BottomWidgets.Items.Add(widget.Value);
}
}

[ImportMany]
public Lazy[] Widgets { get; set; }
}
}
[/cc]

Выше вы можете увидеть что теперь тип виджетов стал Lazy. К тому же, в пределах цикла у нас есть безопасный для компиляции доступ к widget.Metadata.Location, но теперь мы никогда не сможем создать конкретный класс который реализует IWidgetMetadata, не так ли? Мы не сможем, но MEF сможет Результат не содержит магических строк на стороне импортера, мы получили intellisense, рефакторинг и проверку на этапе компиляции! Так же, обратите внимание мы по прежнему должны получить доступ к значению (widget.Value), что бы получить созданный виджет. На самом деле это преимущество, хотя если мы получим виджет в другом месте, это не будет расточительно. Здесь это не имеет большой разницы, но если мы имели бы 50 виджетов это была бы уже другая история.

Теперь давайте запустим приложение.

Вуаля, мы видим наши виджеты отобразились в нужном месте, и нам не нужно делать сальто назад 1000 раз.

Магические строки зло! И MEF этому ответ.

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

Было бы очень красиво если бы мы могли сделать это следующим образом: [ExportWidget(Location=WidgetLocation.Top)], не так ли? Нам больше не нужен будет Export, а так же все атрибуты ExportMetadata. Это сделает наш код более чистыми и менее шумным.
Хорошая новость, вы можете так сделать.

Пользовательские экспорты

MEF позволяет вам сделать собственный экспорт, который содержит метаданные. Собственный экспорт это ваш собственный атрибут с метаданными, и он строго типизированный.

Давайте создадим наш новый атрибут ExportWidgetAttribute.

[cc lang="csharp"]
using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;

namespace HelloMEF
{
[MetadataAttribute]
[AttributeUsage(AttributeTargets.Class, AllowMultiple=false)]
public class ExportWidgetAttribute : ExportAttribute
{
public ExportWidgetAttribute()
:base(typeof(UserControl))
{
}

public WidgetLocation Location { get; set; }
}
}
[/cc]

Если посмотрим выше, стоит отметить некоторые вещи:
1. ExportWidgetAttribute наследует ExportAttribute. Это то что говорит MEF «Эй, я атрибут экспорта».
2. Базовый конструктор атрибута передается тип UserControl. Этот шаг является критическим, иначе MEF будет использовать конкретный тип на который установлен атрибут.
3. Атрибут имеет установленный атрибут MetadataAttribute, это говорит MEF, что это не только экспорт, но так же предоставляет метаданные. Теперь когда он применился, MEF будет искать каждое публичное свойство атрибута которое я добавил, и будет получать из них метаданные, ключем для которых будет имя свойства. В сущности это добавит [ExportMetadata("Location",…)] с значением присвоенным свойству.
4. Атрибут имеет установленный атрибут [AttributeUsage], указывающий допустимые цели для него, в данном случае классы и так что AllowMultiple = false. Если мы не сделаем это, тогда MEF будет принимать множество наборов метаданных которые существуют и будет возвращать метаданные как массив.

Теперь мы можем изменить каждый из наших виджетов для использования нового атрибута.

Первый Widget1.xaml.cs
[cc lang="csharp"]
using System.Windows.Controls;

namespace HelloMEF
{
[ExportWidget(Location=WidgetLocation.Top)]
public partial class Widget1 : UserControl
{
public Widget1()
{
InitializeComponent();
}
}
}
[/cc]

И затем Widget2.xaml.cs

[cc lang="csharp"]
using System.Windows.Controls;

namespace HelloMEF
{
[ExportWidget(Location=WidgetLocation.Bottom)]
public partial class Widget2 : UserControl
{
public Widget2()
{
InitializeComponent();
}
}
}
[/cc]

Наш собственный атрибут выглядит очень хорошо. Не надо больше указывать контракт, нет больше лишних метаданных, и выглядит очень красиво и компактно. Так же стоит заметить, что наш раздел using включает System.ComponentModel.Composition. Это означает что наши потребители могут использовать MEF даже незнаю что они используют его. Мы только посылаем им наши атрибуты и интерфейсы, и они могут начинать.

Нажмите магическую кнопку Run и вот что вы получите.

Вопросы?

Краткое изложение

В этой статье мы изучили как можем использовать метаданные и Lazy что бы делать красивые вещи с помощью MEF. Мы можем снабжать экспорт информацией, которую импортеры могут использовать чтобы определить могут ли они использовать фрагменты, и как они могут сделать это (например поместить фрагмент в верхнее положение). Мы так же узнали, как можно создать собственный атрибут экспорта.

Что дальше?

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

There’s much more to come after that, the series is shaping up!

1. sensing a pattern here?
2. Value rather than the widget value directly

Обсуждение Axonframework CQRS Framework с его разработчиком в InfoQ
лента твиттов о CQRS
Google группа Discussions about DDD, CQRS, and Event Sourcing

Видео и слайды
Выступление Greg Young на QCon
Видео и слайды выступления Udi Dahan на встрече .NET User Group в Лондоне
Видео выступления Джонатана Оливера на Utah Code Camp
Введение для новичков от Джонатана Оливера

Примеры приложений
Тестовое приложение использующее DDDD и Ncqrs Framework
Пример использования фреймворка Fohjin

Фреймворки CQRS
.NET
NCQRS Framework
Agr.CQRS
Fohjin

Java
Axon Framework

В довесок ко всему этому создал с помощью Yahoo pipes агрегированный RSS по CQRS

Прошлой ночью я отправил письмо Jeff Atwood в котором была одна строка. «Ты должен сделать Stackoverflow API используя OData». Then I realized that, as Linus says, Talk is Cheap, Show me the Code. Я отвел под это весь 12 часовой полет. Но к сожалению это заняло 30 минут, так что остальное время я смотрел фильмы.

Вы можете следить за процессом и делать это самостоятельно, если хотите.

Подготовка

Перед моим полетом я сделал две вещи.
Во-первых, я скачал утилиту импорта Сэма Саффрона «So Slow» Stackoverflow SQL Server. Это маленькая утилита Сэма, которая берет 3х Гб файл XML ежемесячного дампа Stackoverflow и импортирует его в SQL Server.

Во-вторых, я скачал ежемесячный дамп Stackoverflow. Я скачал его с помощью uTorrent и распаковал его во время подготовки к полету.

Импорт в SQL Server

Я переключился в Visual Studio 2010 (хотя мог бы использовать 2008, но мне понравились улучшения в Entity Framework в 2010, которые позволяют делать работу проще). Правым кликом мыши на узле Data Connections в Server Explorer я создаю базу данных в SQL Express с именем, гмм, «Stackoverflow».

Далее, я открыл в Visual Studio файл Сэма RecreateDB.sql из его проекта (не пользуюсь SQL Server Management Studio, если это возможно) подключился к экземпляру «.\SQLEXPRESS», выбрал новую базу StackOverflow и нажал «Execute».

One nit¹ по поводу SQL файла Сэма, он красиво создает таблицы из дампа, но он не содержит информации о ссылочной целострости. Таблицы никак не связаны с другими и они не имеют cardinality setup². Я перезаписал клетки головного мозга которые знали что с этим делать без Google и Bing, поэтому я решил вернуться к этому позже. И вы тоже.

Далее, я открыл приложение Сэма SoSlow и запустил его. Это мелкое красивое приложение с интуитивным интерфейсом, которое работает так как и обещалось. Как по мне, я бы, наверное назвал кнопку «Import» чем то вроде «Release the Hounds!».

На данный момент я имею базу данных с несколькими сотнями мегабайт публичных данных Stackoverflow.

Создание Веб проекта и Модели сущностей

Итак, я выбрал в Visual Studio File | New Project | ASP.NET Web Application. Затем, я правым кликом на исходном проекте выбрал Add | New Item, then clicked Data, then ADO.NET Entity Data Model.

Что делать с этим, Хансельман? Вы знаете что Stackoverflow использует LINQ to SQL? Вы наконец продались и скрытно пытаетесь заставить нас использовать Entity Framework с помощью этого замаскированного сообщения?

Нет. Я использую EF по нескольким причинам. Во-первых, в Visual Studio 2010 он настолько быстрый (и во время выполнения (runtime) и во время проектирования (design time) ), что я больше не замечаю разницы. Во-вторых, я знал что отсутствие ссылочной целостности приведет к проблеме (помните, я говорил об этом ранее?) и так как маппинг в LINQ to SQL 1:1³, а EF предлагает гибкий маппинг, я понял что будет легче сделать это с EF. В-третьих, «WCF Data Services» (сервисы данных ранее известные как ADO.NET Data Services или «Astoria») отлично маппяться на EF.

Я назвал файл StackOverflowEntities.edmx и нажал «Update Model from Database» и для начала выбрал все таблицы. Когда открыл дизайнер, я заметил что нет линий связи, только таблицы.

Итак, я оказался прав насчет того что между таблицами в SQL Server небыло связей. Я бы подключился к SQL Server`у для добавления этих связей, но подумал что могу добавить их здесь так же хорошо как и другие вещи которые сделают нашу работу с OData Service более приятной.

Я начал просматривать таблицу сообщений (Posts) и представлять что если я смотрю на сообщения, то захочу видеть комментарии (Comments). Поэтому я щелкнул правой кнопкой мыши на таблице Posts и выбрал Add | Association. Потратив секунду на понимание появившегося диалога (я никогда не видел его ранее), я понял, что он делает, то о чем написано в предложении снизу, поэтому я сосредоточился чтобы это предложение было верным. В данном случае, «Post can have * (Many) instances of Comment. Use Post.Comments to access the Comment instances. Comment can have 1 (One) instance of Post. Use Comment.Post to access the Post instance.⁴ то что я хотел. Также, у меня были свойства с внешними ключами, поэтому я отключил их и нажал кнопку OK.

Это привело меня в дизайнер. Обратите внимание на линию с текстом 1..* и на свойства навигации: Comments в классе Post и Post в классе Comment. Все это появилось из прошлого диалога.

Потом, после того как я понял что у меня нет внешнего ключа в виде автоматического свойства, и я должен замаппить его сам. Дважды щелкнул на линию ассоциации. Выбрал класс Post как главный элемент (Principal) и связал его свойство Id с свойством PostId класса Comments.

Поняв это, я просто создал все очевидные связи для таблиц, которые видны на диаграмме, где Users (Пользователи) имеют Badges (идентификационные данные), Posts (сообщения) имеют Votes (голоса), и так далее.

Теперь, давайте создадим сервис.

Создание OData сервиса

Нажав правой кнопкой мыши на проект в Solution Explorer выбрал Add | New Item | Web | WCF Data Service. Я назвал его Service.svc. Все что вам необходимо для создания полноценного работающего OData сервиса это добавить класс между угловыми скобками (DataService) и добавить код одну строку config.EntitySetAccessRule. Вот мой исходный класс. Я добавил SetEntitySetPageSize, после того как я попытался получить все сообщения.
[CSharp]
public class Service : DataService
{
// Этот метод вызывается только один раз для инициализации всех политик сервиса.
public static void InitializeService(DataServiceConfiguration config)
{
config.SetEntitySetAccessRule(«*», EntitySetRights.AllRead);

//Устанавливаем приемлемый размер страницы
config.SetEntitySetPageSize(«*», 25);

config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
}
}
[/CSharp]
Расширяя этот класс, я добавил кеширование, и пример операции сервиса, так же как WCF Data Services support for JSONP. Обратите внимание что операция сервиса это лишь пример чтобы показать что StackOverflow может иметь полный контроль⁵. Использование OData не означает установить флажок и вывести свою базу данных в сеть. Это подразумевает выделение ограниченного количества сущностей с большой или малой детализацией, так как нравится вам. Вы можете перехватывать запросы, создавать настраиваемые поведение (например такое как JSONP), создавая настраиваемые операции сервиса (они могут содержать строки запросов, конечно же), и многое другое. OData нативно поддерживает формат JSON, и будет возвращать JSON если заголовок установлен, но я добавил поддержку JSONP что бы позволить междоменное использование сервиса, а так же форматировать параметры в URL, потому что так понятнее и легче для человека.
[CSharp]
namespace StackOveflow
{
[JSONPSupportBehavior]
public class Service : DataService
{
// Этот метод будет вызван один раз для инициализации всех политик сервиса.
public static void InitializeService(DataServiceConfiguration config)
{
config.SetEntitySetAccessRule(«*», EntitySetRights.AllRead);

// Здесь могло бы быть «*» и так же ReadSingle, и тд.
config.SetServiceOperationAccessRule(«GetPopularPosts», ServiceOperationRights.AllRead);

// Установим разумный размер страницы
config.SetEntitySetPageSize(«*», 25);

config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
}

protected override void OnStartProcessingRequest(ProcessRequestArgs args)
{
base.OnStartProcessingRequest(args);
// Минутный кеш, на основе строки запроса
HttpContext context = HttpContext.Current;
HttpCachePolicy c = HttpContext.Current.Response.Cache;
c.SetCacheability(HttpCacheability.ServerAndPrivate);
c.SetExpires(HttpContext.Current.Timestamp.AddSeconds(60));
c.VaryByHeaders["Accept"] = true;
c.VaryByHeaders["Accept-Charset"] = true;
c.VaryByHeaders["Accept-Encoding"] = true;
c.VaryByParams["*"] = true;
}

[WebGet]
public IQueryable GetPopularPosts()
{
var popularPosts = (from p in this.CurrentDataSource.Posts
orderby p.ViewCount
select p).Take(20);

return popularPosts;
}
}
}
[/CSharp]
Но что это нам дало?

Доступ к данным StackOverflow через OData

Хорошо, если я открою http://mysite/service.svc Я увижу этот сервис. Обратите внимание на относительные ссылки (HREFs).

Если я открою http://173.46.159.103/service.svc/Posts Я получу сообщения (постраничные, как я упоминал). Посмотрите на это более детально. Обратили внимание на содержимое тегов до содержимого? Обратили внимание на атрибут href с относительной ссылкой href=»Posts(23)»?

Помните все те связи которые Я настроил ранее? Теперь Я могу посмотреть:

• Получить сообщение: http://173.46.159.103/service.svc/Posts(23)/
• Получить голосование за данное сообщение: http://173.46.159.103/service.svc/Posts(23)/Votes
  /li>

• Получить сообщение и все комментарии одновременно: http://173.46.159.103/service.svc/Posts(23)?$expand=Comments
• Я даже могу перейти к просмотру информации о пользователе прокомментировавшего сообщение: http://173.46.159.103/service.svc/Posts(23)/Comments(55049)/User

Но это все только навигация. Я также могу делать запросы. Скачайте LINQPad Beta for .NET 4. Peep this. Нажмите на Add Connection, и укажите мой маленький тестовый сервер Orcsweb.

Оговорка: Это тестовый сервер Orcsweb который может остановиться в любой момент. Так же отметим, что вы можете зарегистрироваться на http://www.vs2010host.com/ и получить свой сервер или найти ASP.NET хостинг или разместить ваш OData сервис в облаке.

Я ввел это и нажал OK.

Теперь я пишу LINQ запросы для StackOverflow через сеть. Нет Twitter подобного API, JSON так или иначе может сделать это. Данные StackOverflow предназначены для OData. Чем больше я вожусь с ними тем больше понимаю что это верно.

На самом деле этот LINQ запрос можно преобразовать в URL. Кроме того для этого вам не нужен .NET, только HTTP:
http://173.46.159.103/service.svc/Posts()?$filter=substringof(‘SQL’,Title) or substringof(‘<sql-server>’,Tags)
Попробуйте то же самое с заголовком: application/json или просто добавьте к запросу параметр $format=json
http://173.46.159.103/service.svc/Posts()?$filter=substringof(‘SQL’,Title) or substringof(‘<sql-server>’,Tags)$format=json
Это автоматически возвратит данные в формате JSON или Atom, если вы этого захотите.
Если у вас есть Visual Studio, быстро создайте консольное приложение. File | New Console App, потом правым щелчком мыши добавьте Add Service Reference. Добавьте туда http://173.46.159.103/service.svc и нажмите кнопку OK.

Попробуйте что нибудь подобное. Я добавил в комментарии URI, что бы показать вам что тут нет обмана.
[CSharp]
class Program
{
static void Main(string[] args)
{
StackOverflowEntities so = new StackOverflowEntities(new Uri(«http://173.46.159.103/service.svc»));

//{http://173.46.159.103/service.svc/Users()?$filter=substringof(‘Hanselman’,DisplayName)}
var user = from u in so.Users
where u.DisplayName.Contains(«Hanselman»)
select u;

//{http://173.46.159.103/service.svc/Posts()?$filter=OwnerUserId eq 209}
var posts =
from p in so.Posts
where p.OwnerUserId == user.Single().Id
select p;

foreach (Post p in posts)
{
Console.WriteLine(p.Body);
}

Console.ReadLine();
}
}
[/CSharp]
Я мог бы продолжить с примерами на PHP, JavaScript, и так далее, но поставлю на этом
точку.

Заключение

StackOverflow всегда был невероятно открыт и щедрый на свои данные. Предположу что OData предложит нам гораздо более гибкий доступ к своим данным чем настраиваемый XML и/или JSON API которые должны быть постоянно корректироваться.
С проприетарным API, люди кинуться создавать клиентов для StackOverflow на разные языках, но эта работа уже сделана с помощью OData включая библиотеки для iPhone и Java. Вот растущий список OData SDK которые могут быть использованы для взаимодействия с подобными сервисами. Я могу загрузить данные в Excel с помощью PowerPivot, если мне это понравится.

Так же, сервис может быть полностью расширен за пределы этого простого GET запроса. Вы можете полностью реализовать CRUD операции с помощью OData и оно ни коим образом не будет связана с .NET. Может быть TweetDeck для StackOverflow?

Я надеюсь мы воодушевим StackOverflow потратить больше чем 30 минут, которые я потратил на это, и сделать достойный OData сервис для своих данных, чем тратить время на создание специализированного API. Я добровольно помогу в этом. Если нет, то мы можем сделать это сами с дампом их данных (еженедельным, надеюсь они могут это ускорить?) и облачным экземпляром.

Вопросы?

1. One nit
2. cardinality setup
3. LINQ to SQL is 1:1 physical/logical
4. Сообщение может иметь много комментариев. Используйте Post.Comments для доступа к коментариям. Коментарий может иметь один экземпляр Сообщения. Используйте Comment.Post для доступа к экземпляру Сообщения
5. to show StackOverflow that they CAN have total control

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

JsonExtension.cs
[CSharp]
using System.IO;
using System.Runtime.Serialization.Json;
using System.Text;

namespace JsonGenericExtExample
{
public static class JsonExtension
{
///

/// Объект /// строка содержащая сериализованный обеъкт в формате Json
public static string GetJson(this T data) where T : class
{
string result;
using (var stream = new MemoryStream())
{
var serializer = new DataContractJsonSerializer(typeof(T));
serializer.WriteObject(stream, data);
var reader = new StreamReader(stream);
stream.Position = 0;
result = reader.ReadToEnd();
}
return result;
}

///

/// Тип результирующего объекта
/// Json строка /// Десериализованный объект
public static T Get(this string data) where T : class
{
var deserializer = new DataContractJsonSerializer(typeof(T));

using (var stream = new MemoryStream(Encoding.UTF8.GetBytes(data)))
{
stream.Position = 0;
return deserializer.ReadObject(stream) as T;
}
}
}
}

[/CSharp]

Для использования достаточно вызвать созданный ранее метод.
[CSharp]
// создаем тестовый экземпляр типом User
var CurrentUser = new User
{
FirstName = «Карим»,
LastName = «Офигенов»,
Age = 124
};
// вызываем extension метод у экземпляра для сериализации в JSON
string jsonString = CurrentUser.GetJson();

// Десериализуем
var DeserializedUser = jsonString.Replace(«Карим»,»Макар»).Get();
[/CSharp]
Использование этих методов очень простое, мало того они теперь будут у всех типов объектов в проекте.

Скриншот тестового приложения

Исходники проекта

Итак, опишем задачу. Silverlight приложение позволяет вводить текст и отсылать его на сервер, где эти данные обрабатываются PHP скриптом – вычисляется MD5 хеш, который отсылается клиенту, полученные данные отображаются в ТеxtBox.

Примечание: В  Silverlight 4 RC функций по вычислению MD5 хеша все еще нет, хотя при непродолжительном поиске можно найти готовые классы.

Создание клиента

Для начала создадим стандартный проект  Silverlight Application. Добавим  в главную и единственную форму: TextBox для ввода отсылаемых данных, кнопку, которая инициирует отсылку и TextBlock который и будет отображать ответ, открываем MainPage.xaml и добавляем следующий текст:

[XML]
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
d:DesignHeight="300" d:DesignWidth="400">

Width="400" Height="300">










VerticalAlignment="Center" HorizontalAlignment="Right"/>
VerticalAlignment="Center" HorizontalAlignment="Right"/>
BorderBrush="Black" BorderThickness="1"
TextWrapping="Wrap"/>
BorderBrush="Black" BorderThickness="1"/>
HorizontalAlignment="Left" VerticalAlignment="Top" Grid.Row="3" Grid.Column="1"
Click="SendButton_Click"/>


[/XML]

С разметкой формы закончили, перейдем к разработке клиентской логики.

1. По нажатию кнопки «SendButton» отправляем текст из текстового поля «inputText».
2. При получении данных отображаем их в поле «ReceivedText».

Двойной клик мыши по кнопке «SendButton» автоматически создаст обработчик события Click,  остается только его наполнить смыслом:

[CSharp]
// Если поле ввода пустое, то ничего не делаем
if (String.IsNullOrEmpty(inputText.Text)) return;
// Создаем экземпляр класса WebClient
var client = new WebClient();
// Адрес серверной части
var uri = new Uri(«http://localhost/index.php»);
// задаем обработчик события UploadStringCompleted
client.UploadStringCompleted += new UploadStringCompletedEventHandler(UploadStringCompleted);

// передаем данные на сервер
client.UploadStringAsync(uri, inputText.Text);
[/CSharp]

Чуть выше мы реализовали метод для отправки данных, и там же подписались на событие UploadStringCompleted. Это событие возникает когда данные отправлены и получен ответ от сервера, для проверки этого достаточно добавить в index.php команду sleep(10), это добавить паузу 10 секунд в обработку запроса. В методе [CSharp light=true]void UploadStringCompleted(object sender, UploadStringCompletedEventArgs e)[/CSharp] мы и реализуем логику:
[CSharp]
void UploadStringCompleted(object sender, UploadStringCompletedEventArgs e)
{
if (e.Error == null)
{
ReceivedText.Text = e.Result;
}
}
[/CSharp]
А логика простая, если не возникло ошибок, то отображаем содержимое в ReceivedText.

Создание сервера

Получили код который отсылает данные на сервер. Серверную часть напишем на PHP, потому как WCF сервис в Apache ну никак не захостится. Создаем файл index.php со следующим содержимым:
[PHP]
$data = file_get_contents('php://input');
if ($data) {
echo md5($data);
}
else {
echo "";
}
?>
[/PHP]
Тут все просто для PHP программиста, а вот для меня этот код стоил 2 часов времени, если не больше. Дело в том, что отсылая данные на сервер и не указывая дополнительных заголовков, они не попадают в массив $_POST. Добраться до них можно только таким способом – file_get_contents(‘php://input’). По полученным данным вычисляется хеш md5 и возвращается обратно.

Примечание

Для того чтобы клиентское приложение могло обращаться к серверу рядом с index.php нужно создать файл crossdomain.xml со следующим содержимым:
[XML]





[/XML]

Скрин запущенного приложения

Исходники проекта

В следующей статье усложним задачу и будем передавать JSON данные из Silverlight в PHP.

]]> http://blog.zzlab.ru/coding/vzaimodejstvie-silverlight-prilozheniya-s-php.html/feed 3 http://blog.zzlab.ru/perevod/razrabotka-prilozheniya-hello-mef-na-silverlight-4-chast-i.html http://blog.zzlab.ru/perevod/razrabotka-prilozheniya-hello-mef-na-silverlight-4-chast-i.html#comments Mon, 15 Mar 2010 22:09:16 +0000 AlexandrYZ http://blog.zzlab.ru/?p=58 Автор: Glenn Block
Оригинал: Building the Hello MEF dashboard in Silverlight 4 – Part I

В моем прошлом посте я продемонстрировал основы Managed Extension Framework с помощью приложения Hello MEF, которое я использовал на PDC. В этой серии постов, мы создадим приложение с нуля о чем и будем говорить в будущем. Это займет несколько статей, я пока не уверен в этом, давайте посмотрим Мы создадим приложение в итеративном стиле, по пути пересматривая отдельные компоненты чтобы вносить новую функциональность.

До того как вы продолжите, сделаю анонс тем, которые мы по пути рассмотрим:

• Экспорт / Импорт и инициализатор компонентов.
• Экспорт метаданных.
• Настраиваемый экспорт.
• Переопределение инициализатора компонентов.
• Динамическая загрузка XAP.

В этом посте мы рассмотрим только первый пункт.
Что-бы продолжить вам необходим Silverlight 4 и Silverlight 4 Toolkit. Вы можете скачать Silverlight 4 здесь и toolkit здесь.

Приложение

Ниже снимок экрана приложения.

Может оно и выглядит не очень сложно, но на самом деле это довольно обманчиво. Приложение представляет собой простую оболочку. Два виджета «Hello MEF» которые вы видите на самом деле обнаружены и экспортированы с помощью MEF. Само по себе приложение не знает о том что нужно искать, но оно умеет размещать предоставленные эй элементы, для этого оно содержит разные области на экране. Если вам знакома технология Prism, принципиально они очень похожи, но вместо модулей контент помещается в области, MEF достает контент отовсюду где это возможно. Подробнее об этом далее.

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

Шаг 1 – Создание приложения

Тут ничего сложного, просто создайте новое Silverlight приложение. Введите «HelloMEF» в качестве имени.

Оставьте отмеченным пукт «Host the Silverlight application in a new Web Site». Мы используем это позже для разделения XAP.

Шаг 2 – Создание интерфейса панели

Для нашей панели мы создадим что нибудь очень и очень простое. Но так чтобы оно работало. Мы создадим StackPanel с двумя элементами управления, которые будут содержать наши виджеты. Перейдите к вашему MainPage.xaml и вставьте следующее.
<UserControl x:Class=«HelloMEF.MainPage»
xmlns=«http://schemas.microsoft.com/winfx/2006/xaml/presentation»
xmlns:x=«http://schemas.microsoft.com/winfx/2006/xaml»
xmlns:d=«http://schemas.microsoft.com/expression/blend/2008″
xmlns:mc=«http://schemas.openxmlformats.org/markup-compatibility/2006″
mc:Ignorable=«d»
d:DesignHeight=«300″ d:DesignWidth=«400″>
<StackPanel x:Name=«LayoutRoot» Background=«Black»>
<Border Background=«Cyan»>
<ItemsControl x:Name=«TopWidgets» Height=«Auto» FontSize=«30″></ItemsControl>
</Border>
<Border Background=«Yellow»>
<ItemsControl x:Name=«BottomWidgets» Height=«Auto» FontSize=«30″></ItemsControl>
</Border>
</StackPanel>
</UserControl>

Шаг 3 Поиск и отображение виджетов – множественный Импорт

Наша панель должна сама заполнять себя виджетами. Первое о чем мы должны подумать это что же такое виджет В MEF когда у нас есть концепт контракта. Контракт представляет собой нечто что может обеспечивать (exported) или потреблять (imported). Самый легкий путь подумать об этом сейчас это задуматься о типе расширения. В случае нашей панели давайте допустим что каждый виджет это UserControl. Мы могли бы создать новый базовый тип или интерфейс, но нам это не нужно.
Это хорошо сделает сам UserControl.
Итак мы должны указать для MEF что нам нужна коллекция UserControl, те мы хотим импортировать много UserControl. И для этого у нас есть атрибут ImportMany. Для начала добавим ссылки на сборки System.ComponentModel.Composition.dll и  System.ComponentModel.Composition.Initialization.dll. Для поиска их вам необходимо отрыть директорию Silverlight SDK (C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client¹). Далее перейдите в code-behind класса MainPage и перепишите класс следующим кодом:

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;

namespace HelloMEF
{
public partial class MainPage : UserControl
{
public MainPage()
{
InitializeComponent();
}

[ImportMany]
public UserControl[] Widgets { get; set; }
}
}

По сути мы говорим «MEF, дай мне виджеты»
Как только мы получим виджеты, мы должны показать их на экране. Сейчас давайте предположим что все виджеты будут запущены в одном ItemsControl. Давайте добавим логику в конструктор.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;

namespace HelloMEF
{
public partial class MainPage : UserControl
{
public MainPage()
{
InitializeComponent();
foreach (var widget in Widgets)
TopWidgets.Items.Add(widget);
}

[ImportMany]
public UserControl[] Widgets { get; set; }
}
}

Шаг 4 – Создание виджета – Экспорт.

Теперь, когда мы получили базовую конфигурацию панели, давайте создадим виджет. Правым кликом мыши на проекте «HelloMEF» добавьте новый Silverlight UserControl с именем Widget1.

Наш виджет будет очень простой кнопкой.  Откройте Widget1.xaml и вставьте следующий код.

<UserControl x:Class=«HelloMEF.Widget1″
xmlns=«http://schemas.microsoft.com/winfx/2006/xaml/presentation»
xmlns:x=«http://schemas.microsoft.com/winfx/2006/xaml»
xmlns:d=«http://schemas.microsoft.com/expression/blend/2008″
xmlns:mc=«http://schemas.openxmlformats.org/markup-compatibility/2006″
mc:Ignorable=«d»
d:DesignHeight=«300″ d:DesignWidth=«400″>
<Grid x:Name=«LayoutRoot» Height=«Auto»>
<Button x:Name=«Button» Content=«Hello MEF!» Width=«300″ Height=«100″></Button>
</Grid>
</UserControl>

Теперь необходимо указать MEF что мы хотим обеспечить импорт наших виджетов в элементы типа UserControl. Для того мы экспортируем их. Откройте Widget.xaml.cs и замените его содержимое этим:

using System;
using System.ComponentModel.Composition;
using System.Windows.Controls;
using System.Windows;

namespace HelloMEF
{
[Export(typeof(UserControl))]
public partial class Widget1 : UserControl
{
public Widget1()
{
InitializeComponent();
}
}
}

Как говорилось выше мы добавили атрибут экспорта и указали тип UserControl. Если мы не  будем передавать тип, тогда MEF сделает экспорт Widget1 как он есть, что не имеет особого смысла потому как панель никогда не найдет его! Бывают моменты когда имеет смысл не использовать конкретный тип, но это не тот случай

Шаг 5 – Сборка панели

Хорошо, мы реализовали нашу Панель, указав импорт и создав виджеты. Это означает что если мы запустим приложение, мы увидим виджеты, так? Неверно Попробуйте запустить и вы увидите неприятную ошибку.

Что произошло? Наше свойство с коллекцией виджетов пустое, но почему? Причина ли тому то что мы указали MEF сделать с ними что нибудь? Да мы добавили атрибут ImportMany, но для MEF необходимо что-бы наш класс MainPage знал что свойство нужно для предоставления чего нибудь. Что возвращает нас к прошлой концепции.

В MEF необходимо сделать 3 базовых вещи. Во-первых и во-вторых, объявить экспорт и импорт, что мы уже сделали. В-третьих, указать для MEF начать делать компоновку что-бы выполнить все импорты. Места для этого (вы можете сделать это более чем один раз) находятся там где есть один и более импортов и нет экспорта. В данном случае экспорт виджетов мы делаем в классе MainPage, поэтому оно и будет таким местом.

Примечание: Мы не поместим это в виджеты, что-бы они самостоятельно экспортировались. Почему нет? Потому что когда MEF начнет экспорт, он автоматически удовлетворит любые импорты теми компонентами которые он соберет. Существует исключение из этого, но мы рассмотрим это позже.

В общем когда у вас будут пользовательские контролы созданные в XAML, вы будете использовать этот способ. Указание MEF скомпоновать Silverlight занимает всего 12 строк кода. Это действительно очень простой код и 12 строк строк стоят этого.
Шутка

Что-бы указать MEF о компоновке вы должны сделать единственный вызов класса  CompositionInitializer.SatisfyImports(this). В терминах MEF все что импортируется или экспортируется мы будем считать Компонентом, which is why the name². Ниже код который добавлен в MainPage.cs.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;

namespace HelloMEF
{
public partial class MainPage : UserControl
{
public MainPage()
{
InitializeComponent();
CompositionInitializer.SatisfyImports(this);
foreach (var widget in Widgets)
TopWidgets.Items.Add(widget);
}

[ImportMany]
public UserControl[] Widgets { get; set; }
}
}³

Теперь когда мы запустим приложение, мы увидим наш первый виджет.

Выводы

Хорошо, уже 2:17 АМ⁴, время ложиться спать.  Предполагаю что разработка приложения растянется на несколько постов.
В этой статье мы увидели основы экспорта, импорта и компоновки в MEF. Мы также коснулись концепции контрактов и компонентов, в которую мы углубимся в будущем.
В следующей статье мы затронем следующие темы:

• Обеспечение / Доступ к экспорту метаданных.
• Другие пути импорта и более подробное рассмотрение контрактов.
• Обеспечение настраиваемого экспорта.

ПС: Это не мой обычный стиль повествования. Я следую примеру моего наставника, гуру и вообще классному парню Брэд Адамс. Пожалуйста не стесняйтесь писать фидбак о том как Я могу стать лучше. Жду с нетерпением продолжения этого путешествия с вами.

Исходники прилагаются

Сноски:

¹ В 64 битных операционных системах – C:\Program Files (x86)\Microsoft SDKs\Silverlight

² Непонятно как перевести.

³ В MEF_Preview 9 PartInitializer переименован в CompositionInitializer

⁴ 02:17 ночи

]]> http://blog.zzlab.ru/perevod/razrabotka-prilozheniya-hello-mef-na-silverlight-4-chast-i.html/feed 0