gandjustas' blog

Очередная встреча RUSUG 26.04.2012

noreply@blogger.com (Станислав Выщепан) — Tue, 24 Apr 2012 06:00:00 +0000

Очередная встреча RUSUG состоится 26 апреля, в четверг. Пройдёт она, традиционно, в Технологическом центре компании Microsoft.

Первым докладчиком стану я, буду выступать с докладом «SharePoint Governance для разработчиков». В докладе пойдет речь о том как планировать, создавать и управлять решениями на SharePoint. Какие инструменты для этого есть в SharePoint, как их эффективно использовать и расширять.

Второй доклад будет посвящён лучшим практикам в настройке SQL Server для работы с SharePoint. Об этом расскажет Максим Хлупнов, Архитектор Технологического центра Microsoft.

Планируется проведение трансляции мероприятия, на которую необходима регистрация.

Регистрация на мероприятие и трансляцию: http://rusug.net/Lists/Apr2012Reg/NewForm.aspx

Я участвую в SPCUA 2012.

noreply@blogger.com (Станислав Выщепан) — Wed, 18 Apr 2012 06:00:00 +0000

25 апреля пройдет событие года по теме SharePoint в СНГ – конференция SharePoint Conference Ukraine 2012 (http://spcua.com/). Генеральный партнер конференции Microsoft Украина, организатор – Lizard Soft (http://lizard-soft.com).

Конференция собрала докладчиков и участников не только со всего СНГ — но и из США и Европы. Ее именитыми докладчиками стали Майкл Ноэль (Michael Noel), Пол Свайдер (Paul J. Swider), Павел Вробель (Pawel Wrobel). Microsoft делегировала на конференцию докладчиков из ЕС, российского и украинского офиса Microsoft. Партнеры конференции из Австралии, Великобритании, Польши, России и Украины.

А также на конференции я буду читать доклад “Искусство управления SharePoint: как получить максимальную выгоду для бизнеса” и отвечать на вопросы.

Блеск и нищета Task Parallel Library

noreply@blogger.com (Станислав Выщепан) — Mon, 16 Apr 2012 07:00:00 +0000

Task Parallel Library (пространство имен System.Threading.Tasks) появилась еще в .NET 4, но большой популярностью не пользовалась. На подходе компилятор C# 5, который поддерживает конструкцию async\await. В скомпилированом коде async метод превращается в метод возвращающий Task\Task<T>. Поэтому в скором времени использование TPL станет повсеместным.

Task Parallel Library – имеет очень мощные механизмы: вложенные (nested) задачи, локальные очереди для потоков, чтобы уменьшить латентность, work-stealing алгоритмы для работы, кучи опций запуска задач и продолжений, различные планировщики. Все создано в лучших традициях оптимизации асинхронного кода.

Но, TPL создавался до мозга костей практиками и цели сделать библиотеку удобной для потребителей даже не ставилось судя по всему.

Как это не смешно, то в стандартной библиотеке нету метода, позволяющего обернуть значение T в Task<T>. (Только в .NET 4.5 появился Task.FromResult)
Сам объект Task представляет из себя “задачу”, которая может быть как еще не запущена, так и уже выполняться. Поэтому работа с разными Task_ами будет осуществляться по-разному.
Task не является immutable объектом, метод ContinueWith изменяет саму задачу.
Функция ContinueWith срабатывает при любом завершении задачи, в том числе отмене или ошибке. Необходимо каждый раз указывать флаги.
Исключения внутри задач собираются в один объект, что затрудняет структурированную их обработку.
Метод ContinueWith принимает Func<Task, T>, а не Func<Task, Task>. Это значит что единственный способ связать две задачи – создать вложенную (nested), что может привести к переполнению стека при завершении цепочки вложенных задач.

Последний пункт особенно актуален. Даже был сделан extension-метод Unwrap, который позволяет писать код в виде:

var task = SomeFuncReturningTask(...)
                .ContinueWith(t => SomeOtherFuncReturningTask(t.Result))
                .Unwrap().ContinueWith(...)
                .Unwrap().ContinueWith(...);

Тут надо обратить внимание на пункт 4, вызовы методов станут еще более многословными.

Async\await в C# 5 частично решает проблему, позволяя писать в виде:

var r1 = await SomeFuncReturningTask();
var r2 = await SomeOtherFuncReturningTask();

Но есть еще другие варианты использования где даже async\await не помогает, например рекурсивные функции.

Также для .NET существует библиотека Rx, которая создавалась теоретиками (которые Linq придумали). Причем основная часть Rx была получена составлением монады двойственной к IEnumerable.

Для сравнения “теоретического” и “практического” подхода попробую написать функцию вычисления высоты дерева.

Само дерево:

class Tree<T>
{
    public Tree()
    {
        this.Children = new List<Tree<T>>();
    }

    public T Data { get; set; }
    public List<Tree<T>> Children { get; private set; }
}

Код тестов очень простой:

var t = new Tree<int> { Data = 0 };
for (int i = 1; i < 10 * 1000; i++)
{
    t = new Tree<int>
    {
        Data = i,
        Children = { t }
    };
}

Console.WriteLine(HeightObservable(t, x => x.Children).Wait());
Console.WriteLine(HeightTask(t, x => x.Children).Result);

Высота дерева специально выбрана большой – 10000, чтобы проверить насколько эффективно библиотека работает со стеком.

Функция вычисления высоты на Rx:

static IObservable<int> HeightObservable<T>(T element, Func<T, IEnumerable<T>> childSelector)
{
    return childSelector(element)
            .ToObservable()
            .SelectMany(e => HeightObservable(e, childSelector))
            .Aggregate(0, Math.Max)
            .Select(x => x + 1)
            .ObserveOn(Scheduler.ThreadPool);
}

Последний ObserveOn нужен чтобы не возникало stack overflow. Rx стремится как можно меньше использовать concurrency внутри себя и по-умолчанию большинство вызовов “продолжений”(continuation) выполняется синхронно, что приводит к переполнению стека в рекурсивном вызове.
Если использовать Rx v2, то можно без ObserveOn обойтись.

Теперь на Task\C# 5. Попытка №1

static async Task<int> HeightTask<T>(T element, Func<T, IEnumerable<T>> childSelector)
{
    var max = 0;
    foreach (var child in childSelector(element))
    {
        var v = await HeightTask(child, childSelector);
        if (v > max)
        {
            max = v;
        }
    }
    return await Task.FromResult(max + 1);
}

Падает со stack overflow . Await вычисляет аргумент и получает awaiter у результата. Таким образом идет полный обход всего дерева в первом же await. Кроме этого вычисление высот поддеревьев идет по-очереди. Код не распараллелен.

Чтобы распараллелить код нужна функция IEnumerable<Task<T>> –> Task<IEnumerable<T>>, которая параллельно выполняет задачи и собирает результат в одну последовательность. Такая функция называется ForkJoin.

Первое что пришло в голову написать:

static Task<IEnumerable<T>> ForkJoin<T>(IEnumerable<Task<T>> tasks)
{
    var result = new List<T>();
    //...
    foreach (var task in tasks)
    {
        task.ContinueWith(t => result.Add(t.Result) /*...*/);
    }
    //...
}

Такой код не работает. Падает со stackoverflow на foreach, потому что при получении первого элемента пытается синхронно обойти все дерево.

Нужно написать функцию, которая асинхронно обходит IEnumerable

static Task<int> EnumerateWithTask<T>(IEnumerable<Task<T>> tasks, Action<Task<T>> continuation)
{
    var tcs = new TaskCompletionSource<int>();
    var enumerator = tasks.GetEnumerator();
    Action recursive = null;
    var count = 0;

    recursive = () =>
        {
            Task.Factory
                .StartNew<bool>(enumerator.MoveNext)
                .ContinueWith(t =>
                    {
                        if (t.IsFaulted)
                        {
                            tcs.TrySetException(t.Exception.InnerExceptions);
                        }
                        else if (t.IsCompleted)
                        {
                            if (!t.Result)
                            {
                                tcs.TrySetResult(count);
                            }
                            else
                            {
                                count++;
                                enumerator.Current.ContinueWith(continuation, TaskContinuationOptions.ExecuteSynchronously);
                                recursive();
                            }
                        }
                    }, TaskContinuationOptions.ExecuteSynchronously);
        };

    recursive();
    return tcs.Task;
}

В этой функции вместо итерации используется рекурсия. Так как рекурсия вызывается внутри продолжения Task, то переполнения стека не получается. Функция возвращает Task, которая считает число элементов после окончания обхода последовательности.

Теперь можно написать и ForkJoin:

static Task<IEnumerable<T>> ForkJoin<T>(IEnumerable<Task<T>> tasks)
{
    var result = new List<T>();
    var tcs = new TaskCompletionSource<IEnumerable<T>>();

    Task<int> countTask = null;
    var completedCount = 0;
    var isCompleted = false;

    countTask = EnumerateWithTask(tasks, t =>
            {
                if (!isCompleted)
                {
                    if (t.IsCanceled)
                    {
                        tcs.TrySetCanceled();
                        isCompleted = true;
                    }
                    else if (t.IsFaulted)
                    {
                        tcs.TrySetException(t.Exception.InnerExceptions);
                        isCompleted = true;
                    }
                    else if (t.IsCompleted)
                    {
                        result.Add(t.Result);
                        completedCount++;
                    }

                    if ((countTask.IsCompleted) && completedCount == countTask.Result)
                    {
                        tcs.TrySetResult(result.AsReadOnly());
                        isCompleted = true;
                    }
                }
            });

    countTask.ContinueWith(t =>
        {
            if (!isCompleted)
            {
                if (completedCount == t.Result)
                {
                    tcs.TrySetResult(result.AsReadOnly());
                    isCompleted = true;
                }
            }
        });
    return tcs.Task;
}

Когда писал этот код получил разрыв мозга. Боюсь даже представить что будет если придется такой код читать. Скорее всего в этом коде есть ошибки и он не обрабатывает отмену. Так что для production придется помучаться еще сильнее.

Ну и наконец сам код расчета высоты дерева на Task_ах, попытка №2:

static Task<int> HeightTask<T>(T element, Func<T, IEnumerable<T>> childSelector)
{
    return ForkJoin(childSelector(element).Select(e => HeightTask(e, childSelector)))
            .ContinueWith(t => t.Result.Aggregate(0, Math.Max, x => x + 1));
}

Замеры показывают что Rx проигрывает по времени выполнения Task_ам примерно в 2 раза (на Rx v2). Это при том что реально асинхронных операций нет. Реальная асинхронность сделает разницу незаметной. Сложность кода Rx на порядок (в 10 раз) меньше, чем Tasks.

Новомодные фишки типа async\await не помогли в этой задаче вообще никак. Причиной этому служит то, что Rx спроектирован на основе монад (как и async в F#). Монады позволяют комбинировать вычисления с некоторым контекстом (в данном случае с “продолжениями”) с помощью небольшого набора функций. На базе этих функций можно построить много других.

Async\await – не более чем переписывание кода в компиляторе, никаких монадических конструкций само по себе оно не создает, а TPL не предоставляет средства для композиции. Вот и получаются проблемы на любом коде, сложнее того что в примерах.

Как ни странно но сейчас не существует библиотеки, которая содержит код, решающий проблемы. Максимум некоторые расширения можно найти в примерах на MSDN.

Заключение

Крайне не рекомендую использовать Tasks для высокоуровневого кода. Rx подходит на эту роль гораздо лучше.

Жириновский о SharePoint

noreply@blogger.com (Станислав Выщепан) — Mon, 16 Apr 2012 06:00:00 +0000

via @avishnyakov

SharePoint + Javascript + Visual Studio = Love

noreply@blogger.com (Станислав Выщепан) — Wed, 14 Mar 2012 06:00:00 +0000

Для тех кто еще не знаком с клиентской объектной моделью SharePoint, настоятельно рекомендую ознакомиться с ней. Client OM доступна как в C# (.NET и Silverlight), так и в Javascript.

.NET разработчики обычно не любят javascript, считают его убогим языком, приводящим к куче ошибок. И они в чем-то правы… Основной причиной называют динамическую типизацию и интерпретируемость javascript. На самом деле разработчика нужна не типизация и компиляция, а проверка кода до запуска и подсказки по коду. Обе возможности доступны в Visual Studio с расширениями.

Проверка кода до запуска

Для этого в галерее расширений visual studio есть два расширения:

JSLint – встроенный в VS инструмент проверки кода javascript, который можно найти по адресу http://www.jslint.com/
Javascript parser – расширение, которое парсит js код на лету (читай показывает ошибки) и предоставляет навигацию по коду.

Эти два расширения позволяют отловить наиболее частые ошибки в коде.

Кроме того рекомендую установить jscript editor extensions чтобы редактор был больше похож на редактор кода C#.

Подсказки по коду aka Intellisence

Эта возможность доступна начиная с Visual Studio 2008, но о ней до сих пор знает катастрофически малая часть разработчиков. Чтобы intellicence для js заработал в visual studio, необходимо visual studio дать подсказку откуда брать файлы.

Если вы пишите javascript код в html\aspx\ascx\materpage файлах, то vs автоматически подтягивает все .js файлы из тегов script и серверного контрола ScriptManager. Далее VS парсит файлы и пытается построить подсказку по коду. Если же нужно обновить подсказку, то можно нажать ctrl+shift+j.

Если же код пишется в .js файле, то файлы, которые надо анализировать для построения подсказки надо указать в специальном теге:

///<reference path="c:\scripts\jquery-1.5.1.js"/>

Имя файла можно указать любое, в том числе url с какого-либо CDN.

В VS11 можно не указывать в каждом файле теги script или reference, а задать в настройках самой студии. Но в VS 2010 такой возможности нет.

Также visual studio поддерживает документирующие комментарии для JS, как и для .NET языков. Подробнее описано по ссылке: http://msdn.microsoft.com/en-us/library/bb385682.aspx

Подсказка по коду позволяет набирать код на javascript быстрее и без ошибок в именах классов и функций.

Причем здесь SharePoint?

Клиентская объектная модель SharePoint для JS вполне успешно понимается студией. Это помогает разработчикам писать код работы с ClientOM на js.

Чтобы все заработало нужно подключить следующие файлы:

///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\MicrosoftAjax.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\1033\init.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\1033\core.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.Core.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.Runtime.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\CUI.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.Ribbon.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.Exp.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.UI.Rte.debug.js"/>

Причем порядок файлов важен, но какой правильный – никто сказать не может, надо проверять.

И все, дальше можно писать код на js, а студия будет подсказывать имена всех классов и функций клиентской объектной модели.

Весь код:

///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\MicrosoftAjax.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\1033\init.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\1033\core.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.Core.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.Runtime.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\CUI.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.Ribbon.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.Exp.debug.js"/>
///<reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.UI.Rte.debug.js"/>

function showWebTitle() {
    var ctx = SP.ClientContext.get_current();
    var web = ctx.get_web();
    ctx.load(web, 'Title');
    ctx.executeQueryAsync(function () {
        alert(web.get_title());
    }, function myfunction(o, ex) {
        alert(ex.get_message());
    });
}

Развертывание скриптов

Самый простой способ сделать ваш скрипт доступным в SharePoint – с помощью sandboxed решения и элемента CustomAction.

Для этого надо создать новый проект, поместить в него один элемент –модуль, поместить в него файл скрипта и написать в манифесте следующий xml:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="Module1">
  <File Path="Module1\JScript1.js" Url="Module1/JScript1.js" />
</Module>

  <CustomAction Location="ScriptLink"
                ScriptSrc="~site/Module1/JScript1.js"/>
</Elements>

Далее можно нажать f5, написать прямо в строке адреса вызов функции и посмотреть результат. При этом работает интерактивная отладка в Visual Studio.

Скрипты в веб-частях

Если вы собираетесь писать скрипты в веб-частях, то вы можете написать кучу тегов script, аналогично reference, но это приведет к загрузке всех файлов при размещении веб-части на форме, что нежелательно.

Есть очень хороший способ с этим бороться:

Директивы условной компиляции приведут к тому что теги script не попадут в результрующую разметку, а VisualStudio игнорирует эти директивы и нормально показывает intellisence.

Заключение

Несмотря на то что javascript очень недружественный к разработчику язык, хорошие инструменты позволяют писать на нем с тем же уровнем комфорта, как на .NET языках.

Создание Silverlight приложений для SharePoint. Часть 2.

noreply@blogger.com (Станислав Выщепан) — Tue, 13 Mar 2012 06:00:00 +0000

Полгода прошло с тех пор как я опубликовал первую часть статьи. Как раз полгода назад произошло смещение приоритетов веб-разработки Microsoft в сторону HTML5, и злые языки начали пророчить скорую смерть Silverlight. Тем не менее вышла пятая версия SL и, скорее всего, будет еще и шестая. Тем не менее фокус больше смещается в сторону HTML\JS, и по слухам в следующей версии SharePoint будет гораздо больше javascript и гораздо меньше SL.

Поэтому данная статья будет больше обзорной.

Варианты развертывания Silverlight приложений

Как обычно их три:

В sandbox решении в виртуальную файловую систему sharepoint.
В fulltrust решении в физическую файловую систему.
Приложение на внешнем сервере, с использованием fluid application model.

Размещение Silverlight на портале.

Самый часто используемый способ – веб-часть silverlight. Её можно найти в категории Media. Также возможно создание своих веб-частей, которые отображают silverlight приложение, чтобы передать дополнительные параметры и\или сделать fallback. Но лучше такие веб-части не создавать, а воспользоваться расширением для visual studio. А в следующей версии visual studio такая веб-часть доступна “изкаропки”.

Еще один вариант – создание field control на silverlight. Пример можно посмотреть в статье на msdn.

Демо-приложение

Для демонстрации всех способов развертывания напишу простое приложение, при запуске оно будет выводить Title узла, на котором запущено приложение.

Сначала надо добавить в проект SL сборки Microsoft.SharePoint.Client.Silverlight и Microsoft.SharePoint.Client.Silverlight.Runtime. Их можно найти в папке {SharePointRoot}\TEMPLATE\LAYOUTS\ClientBin.

Теперь можно написать немного кода:

var ctx = ClientContext.Current;
var web = ctx.Web;
ctx.Load(web, w => w.Title);

ctx.ExecuteQueryAsync(
(o, args) => //success
{
    Dispatcher.BeginInvoke(() =>
    {
        tbTitle.Text = web.Title;
    });

},
(o, args) => //failure
{
    Dispatcher.BeginInvoke(() =>
        {
            MessageBox.Show(args.Exception.ToString());
        });
});

Для тех кто не знаком с клиентской объектной моделью SharePoint краткий ликбез. Точка входа в клиентскую объектную модель – класс ClientContext, в SL приложении можно получить “текущий контекст”, если приложение развернуто в SharePoint.

Все объекты в клиентской объектной модели являются”обещаниями” (promise), то есть на момент получения они не содержат значений, а только общение что значения когда-нибудь там будут. Чтобы загрузить свойства объекта с сервера надо выполнить метод ClientContext.Load. В методе Load можно указать с помощью лямбда-выражений какие свойства загружать.

Другая особенность клиентской объектной модели заключается в в том что команды не выполняются сразу, а складываются в очередь и отправляются на сервер при вызове ExecuteQuery\ExecuteQueryAsync. Так как в SL нельзя блокировать поток UI, то воспользуемся асинхронным вариантом.

Третья особенность заключается в том что коллбеки завершения асинхронного вызова клиентской объектной модели не маршалятся в поток UI (сколько непонятных слов, сам в шоке). Поэтому надо вызывать Dispatcher.BeginInvoke чтобы поменять что-либо в UI или вывести Message Box.

На первый взгляд код выглядит сложным, но при некоторой сноровке пишется “на автомате”.

Развертывание на уровне фермы

Это самый простой и прямолинейный вариант. Он вполне может быть оправдан если вы используете Silverlight приложение как field control для кастомного поля, в остальных случаях я бы не рекомендовал.

Чтобы развернуть приложение в физическую файловую систему надо создать один пустой элемент (SPI), даже не нужен манифест (Element.xml) и фича, их можно просто удалить.

Далее в необходимо добавить в элемент project output из проекта silverlight, обязательно указав Deployment Type=TemplateFile

После этого надо добавить элемент в package (не в фичу).

Последний шаг перед развертыванием – включить отладку Silverlight.

После этого можно жать F5 на проекте SharePoint, добавлять на страницу веб-часть Silverlight и ставить точки останова в проекте Silverlight.

Развертывание в sandbox

Для развертывания решения в sandbox надо выполнить те же шаги, что и для fulltrust решения, но вместо пустого элемента создать модуль, указать Deployment Type=ElementFile в project output references и использовать фичу для развертывания.

И все, в манифест модуля автоматически попадет элемент с xap файлом.

Далее как обычно: F5, веб-часть, отладка.

Развертывание на внешнем хосте

Для начала надо включить поддержку внешних приложений в SharePoint. Это можно сделать в powershell небольшим скриптом.

$cs = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$cs.ExternalApplicationSettings.Enabled = $true
$cs.Update()

Я не проверял включены ли внешние приложения в office 365, очень надеюсь что включены. Иначе я зря это все пишу.

Чтобы разместить внешнее приложение в SharePoint надо передать веб-части silverlight манифест приложения (applicationXml). При добавлении веб-части появится запрос манифеста (после включения внешних приложений).

<?xml version="1.0" encoding="utf-8" ?>
<applicationParts xmlns='http://schemas.microsoft.com/sharepoint/2009/fluidapp'>
  <applicationPart>
    <metaData>
      <applicationId>F0F0E6C1-5B42-4277-9EFF-777F1330BCD8</applicationId>
      <applicationUrl>http://localhost:21351/HostWebSite/ClientBin/SlApp.xap</applicationUrl>
      <principal>contoso\sp-app</principal>
      <sharepointRequestHandlerUrl>/HostWebSite/sp.ashx</sharepointRequestHandlerUrl>
    </metaData>
    <data>
      <webPartProperties>
        <property name='Title'>SlApp</property>
        <property name='Height'>400px</property>
        <property name='Width'>300px</property>
        <property name='MinRuntimeVersion'>3.0</property>
      </webPartProperties>
      <customProperties>
      </customProperties>
    </data>
  </applicationPart>
</applicationParts>

До того как создавать веб-часть необходимо дать доступ пользователю, который указан в разделе principal, с помощью метода AddApplicationPrincipal. Лучше всего это делать в коде активации фичи.

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    var web = properties.Feature.Parent as SPWeb;
    var principal = web.AddApplicationPrincipal("contoso\\sp-app", true, false);
    web.RoleAssignments.Add(new SPRoleAssignment(principal)
    {
        //Don't do this in podution code
        RoleDefinitionBindings = { web.RoleDefinitions.GetByType(SPRoleType.Administrator) }
    });           
}

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
    var web = properties.Feature.Parent as SPWeb;
    var principal = web.AddApplicationPrincipal("contoso\\sp-app", true, false);
    web.RoleAssignments.Remove(principal);
}

После деплоя решения и активации фичи можно попробовать добавить на страницу веб-часть Silverlight и указать application xml. Приложение отобразится но сразу будет падать с ошибкой.

Небольшой ликбез про кросс-доменные вызовы в silverlight. По умолчанию приложение на SL может обращаться только к тому домену, откуда оно загружено. В модели external application в sharepoint приложение silverlight находится в другом домене и ему кросс-доменные вызовы запрещены.

Иногда может помочь файл clientaccesspolicy.xml, который разрешает silvelight обращаться за пределы домена, но там надо явно прописать куда можно обращаться или указать что обращаться можно везде. Но это небезопасно, так как в случае sharepoint приложение на Silverlight будет передавать пароль по сети для аутентификации.

Поэтому сделана такая система. В манифесте приложения указывается куда silverlight приложение будет отправлять запросы при вызове клиентской объектной модели (элемент sharepointRequestHandlerUrl). Обработчик по указанному url будет определять какой сайт sharepoint обращается и передавать логин и пароль именно для этого сайта.

Чтобы создать этот обработчик надо в сайте, где хостится silverlight создать обычный ashx-хендлер.

public class sp : IHttpHandler {
    
    public void ProcessRequest (HttpContext context) {
        RequestForwarder forwarder = new RequestForwarder(context);
        if (!String.IsNullOrEmpty(forwarder.Url))
        {
            forwarder.WebRequest.Credentials
                = new System.Net.NetworkCredential("sp-app", "P@ssw0rd", "contoso");
            forwarder.ProcessRequest();
        }
    }
 
    public bool IsReusable {
        get {
            return false;
        }
    }
}

Класс RequestForwarder находится во “взрослой” клиентской объектной модели.

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

Заключение

Как видите довольно много возможностей развертывания приложений Silverlight в SharePoint. При этом само приложение не поменялось ни в одном сценарии.

Поиск в приложениях SharePoint. Часть 1.

noreply@blogger.com (Станислав Выщепан) — Mon, 12 Mar 2012 06:00:00 +0000

Одна из наиболее часто возникающих задач при разработке порталов на SharePoint - создание веб-части , отображающей ближайшие дни рождения пользователей.

В SharePoint 2010 есть служба профилей пользователей, которая хранит данные о пользователях, в том числе дни рождения, в масштабах фермы. Для отображения списка пользователей можно использовать веб-часть "Основные результаты поиска людей". Но если разместить веб-часть на форму, то она не выводит результатов.

Чтобы отобразить результаты необходимо "Добавить текст в запрос".

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

Веб-часть отображения результатов поиска наследует DataFormWebPart, поэтому можно настроить отображение в виде xslt. Но для этого надо отключить отображение по-умолчанию.

XSL для отображения:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
  <table>
    <tr>
      <th>
        User name
      </th>
      <th>
        Account name
      </th>
    </tr>
    <xsl:apply-templates select="All_Results/Result"/>
  </table>
</xsl:template>
  <xsl:template match="Result">
    <tr>
      <td>
        <xsl:value-of select="preferredname"/>
      </td>
      <td>
        <xsl:value-of select="accountname"/>
      </td>
    </tr>
  </xsl:template>
</xsl:stylesheet>

Веб-части поиска выводят управляемые свойства поиска, которые задаются в central administration. Чтобы выводить (и использовать в запросах) дату рождения необходимо создать управляемое свойство, которое отображается на свойство профиля.

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

После обходи можно добавить элемент в свойства columns веб-части и дописать xslt для вывод нужного значения.

Даты в профиле пользователя вводятся в формате “Месяц День”, 2000 год дописывается сам (чтобы можно было 29 февраля ввести). При выводе вам надо самостоятельно форматировать даты.

Теперь остается две проблемы:

Сортировка результатов. По-умолчанию веб часть не поддерживает сортировку по произвольному полю.
Динамический запрос. В параметрах веб-части можно ввести только статическую строку и получить текущую дату нельзя.

Для того чтобы победить обе проблемы можно наследоваться от веб-части поиска, но веб-часть поиска людей sealed. Поэтому надо наследоваться от веб-части поиска контента.

Для этого нужно создать веб-часть в visual studio.

public class WebPart1 : CoreResultsWebPart
{
    protected override string DefaultSearchLocation
    {
        get
        {
            //For people search
            return "LocalPeopleSearchIndex";
        }
    }

    protected override void ConfigureDataSourceProperties()
    {
        base.ConfigureDataSourceProperties();

        var ds = this.DataSource as CoreResultsDatasource;
        ds.SortOrder.Clear();
        ds.SortOrder.Add("Birthday", Microsoft.Office.Server.Search.Query.SortDirection.Descending);
    }

    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);

        var today2000 = new DateTime(2000, DateTime.Today.Month, DateTime.Today.Day);           
        this.AppendedQuery = string.Format("Birthday>=\"{0}\" AND Birthday<\"{1}\" ", 
                                    today2000.ToShortDateString(),
                                    today2000.AddDays(3).ToShortDateString());
    }
}

Свойство AppendedQuery – это “Добавить текст в запрос” в интерфейсе.

Результат после размещения на форме и правки представления:

Заключение

Стандартные веб-части поиска – очень мощный механизм вывода данных. Если мощности стандартных веб-частей не хватает, то их очень легко расширить с помощью кода.

Миф о кастомизации страниц в SharePoint

noreply@blogger.com (Станислав Выщепан) — Tue, 31 Jan 2012 06:00:00 +0000

Немного теории. В SharePoint есть виртуальная файловая система, которая содержится в контентной БД. Когда вы в farm solution помещаете в нее файл, с помощью модуля, то файл лежит на диске в {SharePointRoot}\TEMPLATE\Features, а контентной БД появляется ссылка на этот файл.

Таким образом экономится место в БД, ведь один и тот же файл может быть добавлен на несколько сайтов. Кроме того упрощается обновление – достаточно обновить файл на диске.

Такие файлы называются uncustomized, ghosted (в терминологии 2007 шарика) или просто некастомизироваными. Если же попробовать внести какое-либо изменение в файл в виртуальной файловой системе (!), то измененное состояние файла записывается в контентную БД и SharePoint перестает обращаться к диску за файлом. такие файлы называются customized, unghosted или кастомизированные.

Причем это относится не только к файлам в виртуальной ФС, но и к типам контента, шаблонам списков итд. Но об этом другой раз…

Миф

Кастомизированные страницы работают медленнее некастомизированных.

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

Я решил просто померить как изменяется скорость работы SharePoint от кастомизации страниц. Сделал простой веб-тест в Visual Studio, который обращается к странице по-умолчанию, а потом создал нагрузочный тест и замерял Page Response Time.

Вот график (кликабельно):

Центральный пик - сохранение кастомизированной страницы, слева - время ответда для некастомизированной старницы, справа - время ответа кастомизированной страницы. Среднее время ответа некастомизированной страницы – 1.7 сек, кастомизироанной – 1.9 сек. Разница около 10%. Если на странице будут “тяжелые” контролы, то разница станет еще менее заметной.

При кастомизации мастер страницы график еще интереснее:

Большой пик – кастомизация мастер-страницы. Справа пик поменьше – было сделано Revert To Definition для мастер-страницы. Получается результаты почти одинаковые, за исключением того, что для некастомизированного masterpage результаты гораздо менее стабильны.

Заключение

Использовать исключительно некастомизированные страницы имеет смысл только для hiload публичных сайтов. Хотя кто использует sharepoint для hiload сценариев???….

Оптимизация процессинга в Windows Azure. Часть 3.

noreply@blogger.com (Станислав Выщепан) — Wed, 11 Jan 2012 06:00:00 +0000

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

А нужны ли вообще воркеры?

Оказывается не нужны. Если у вас небольшое приложение и вы используете очереди для надежной (reliable) асинхронной обработки, причем сама обработка не требует больших вычислительных затрат, то вам и не нужны воркеры. Можете использовать пару методов ToObserver\ToObservable из предыдущего поста, а для оповещений обычный Subject<Unit>.

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

Scale Down

Как вы уже могли догадаться возможность масштабировать “вниз” в облаке не менее важна, чем масштабирование “вверх”. С учетом всех ранее перечисленных подходов можно любое приложение развернуть на одном Extra Small Instance в Windows Azure за $30 и тысячей транзакций хранилища (меньше $0.01) в месяц, если к нему будет мало обращений. Это уже сопоставимо с ценой shared-хостинга.

На этом история scale down заканчивается и начинается история…

Scale Up\Out

Сразу же рекомендую посмотреть на Autoscale Application Block (кодовое имя WASABi) из комплекта Enterprise Library. Ссылка на Enterprise Library 5.0 Windows Azure Integration Pack. Этот модуль позволяет задавать правила в соответствии с которыми будет изменяться количество экземпляров ролей в вашем приложении.

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

К сожалению Windows Azure тут не исключение. В блоге Windows Azure Storage описаны scalability targets. Вы можете обнаружить очень интересные сведения о том что максимальное количество сообщений очереди, обрабатываемых в секунду – 500 (по другим сведениям это количество транзакций в секунду). Это очень-очень мало. И надо не забывать что это предельное значение, на практике его достигнуть будет непросто. Кроме того латентность очереди может достигать 100ms.

Первое что необходимо чтобы избежать высокой латентности на маленьких сообщениях в очереди - установить ServicePointManager.UseNagleAlgorithm значение false.

Следующая проблема – максимальный размер сообщения в очереди – 8KB, так как для передачи используется Base64 кодировка, то реально данных можно передать около 6KB, кстати строки по-умолчанию не кодируются. Добрые люди уже придумали как решать такую проблему: http://msdn.microsoft.com/en-us/library/windowsazure/hh690942(v=VS.103).aspx

Масштабирование воркеров

Как вы думаете что будет если взять “наивную” реализацию воркера, как в первом посте и запустить на Extra Large Instance, насколько быстрее будет работать?

На самом деле вообще не будет быстрее. С этой точки зрения большое количество маленьких воркеров лучше чем один большой. Хотя тоже не лучший вариант по словам представителей Microsoft. С другой стороны куча маленьких воркеров будут пинать Azure Storage гораздо чаще, что несомненно отразится на ценнике. Того же можно добиться если запустить вручную несколько потоков с наивным циклом в воркере, развернутом на Medium instance или более крутой машине.

Чтобы этого избежать надо использовать метод CloudQueue.GetMessages. Пример ниже показывает кусок кода для итератора, который потом обрабатывается Rx.

while (true)
{
    var msgsObs = getMessages(32).ToListObservable();
    yield return msgsObs;
    var msgs = msgsObs[0];

    var hasMessages = false;
    foreach (var msg in msgs)
    {
        hasMessages = true;
        idleCount = 0;

        result.OnNext(msg);
    }

    if (!hasMessages)
    {
        var delay = CalulateDelay(idleCount++, MinimumIdleIntervalMs, MaximumIdleIntervalMs, 100);
        if (delay.TotalMilliseconds >= MaximumIdleIntervalMs)
        {
            yield break;
        }

        yield return Observable.Timer(delay).ToListObservable();
    }
}

Обратите внимание что вызов OnNext должен быть упорядочен, чтобы не возникало Race Condition. Это требование указано в Rx Design Guidelines, и если вы его не читали, то крайне рекомендую это сделать.

Кроме того удаление сообщения из очереди в таком коде возлагается на внешний код.

Пример:

from m in queue.ToObservable(notifications)
from _1 in Observable.Start(() => /*work*/, Scheduler.TaskPool)
from _2 in queue.DeleteMessageAsync(m)
select Unit.Default;

Само это выражение не приводит ни к какому эффекту. Для него надо выполнить Subscribe чтобы запустить вычисления. Тогда будет использоваться TaskPool, который довольно эффективно распределяет вычисления по процессорам. Если вычисления длительные (более 10ms - 100ms), то лучше использовать Scheduler.NewThread. Если же у вас IO-bound код, то лучше будет использовать Scheduler.ThreadPool.

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

Вместо одной очереди вы создаете N очередей. При добавлении сообщения в очередь выбираете случайную. Считываете сразу из всех. Надо как-то разбираться из какой очереди пришло сообщение. Реализация такого нетривиальна и уже есть первый подобный проект на codeplex: http://partitioncloudqueue.codeplex.com/.

Но Rx как всегда рулит и с его помощью очень просто сделать такой partitioning.

На клиенте:

List<CloudQueue> queues = /*...*/;
var observers = queues.Select(q => q.ToObserver(/*notifier*/))
                      .ToList();

var rnd = new Random();
var partitionedObserver = Observer.Create<CloudQueueMessage>(
        m => observers[rnd.Next(observers.Count)].OnNext(m),
        e => observers.ForEach(obs => obs.OnError(e)),
        () => observers.ForEach(obs => obs.OnCompleted())
    );
partitionedObserver.OnNext(new CloudQueueMessage(/*message*/));

На сервере:

IObservable<Unit> ProcessMessages(CloudQueue queue, /*notifier*/, /*scheduler*/)
{
    return from m in queue.ToObservable(/*notifier*/)
           from _1 in Observable.Start(/*action*/, /*scheduler*/)
           from _2 in queue.DeleteMessageAsync(m)
           select Unit.Default;
}

/*.....*/

List<CloudQueue> queues = /*...*/;
queues.Select(q => ProcessMessages(q,/*notifier*/, /*scheduler*/))
      .Merge()
      .Subscribe();

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

Заключение

Все описанные выше способы помогут вам более эффективно реализовывать процессинг в Windows Azure. Для тех кто дочитал до сюда – сюрприз. Весь код с примерами использования есть на codeplex, а также библиотека для работы с очередями доступна в NuGet.

Оптимизация процессинга в Windows Azure. Часть 2.

noreply@blogger.com (Станислав Выщепан) — Tue, 10 Jan 2012 06:00:00 +0000

В первой части я показал сколько стоит использование воркер-ролей и очередей в Windows Azure и что с этим можно сделать.

Довольной хороший подход – адаптировать интервал опроса новых сообщений и отключать опрос в случае их отсутствия продолжительное время. Но после выключения надо как-то включать.

Для этого был создан extension-метод:

public static IObservable<CloudQueueMessage> ToObservable<T>(
                                                        this CloudQueue queue, 
                                                        IObservable<T> haveMoreMessages)

Этот метод возвращает сообщения очереди в виде IObservable коллекции. Включение опроса осуществляется появлением элемента в последовательности haveMoreMessages.

Теперь о том как реализовать последовательность haveMoreMessages.

Самый дешевый вариант взаимодействия между экземплярами ролей это internal wcf communication. Для того чтобы работать с WCF необходимо определить контракты.

[ServiceContract]
public interface IQueueNotifier
{
    [OperationContract(IsOneWay = true)]
    void MessageAdded(string queueName);

    [OperationContract(IsOneWay = true)]
    void NoMoreMessages(string queueName);
}

Контракт содержит всего два метода оповещения о новом сообщении в очереди и об окончании сообщений.

Реализация тоже тривиальна:

public class QueueNotifier : IQueueNotifier
{
    private ISubject<string> moreMessages = new Subject<string>();
    private ISubject<string> queueCompleted = new Subject<string>();

    public IObservable<string> MoreMessages
    {
        get
        {
            return this.moreMessages;
        }
    }

    public IObservable<string> QueueCompleted
    {
        get
        {
            return this.queueCompleted;
        }
    }

    public void MessageAdded(string queueName)
    {
        moreMessages.OnNext(queueName);
    }

    public void NoMoreMessages(string queueName)
    {
        queueCompleted.OnNext(queueName);
    }
}

Далее комбинируя два потока получаем IObservable<Unit> пригодный для метода, описанного в начале поста.

public static IObservable<Unit> GetQueueNotifications(this QueueNotifier service, string queueName)
{
    return Observable.Create<Unit>(obs =>
    {
        var sub1 = service.MoreMessages
                          .Where(q => q == queueName)
                          .Subscribe(q => obs.OnNext(Unit.Default));

        var sub2 = service.QueueCompleted
                          .Where(q => q == queueName)
                          .Subscribe(q => obs.OnCompleted());

        return new CompositeDisposable(sub1, sub2);
    });
}

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

Клиентская сторона

Чтобы отправлять оповещения нужно создать ChannelFactory<IQueueNotifier> и получить экземпляр прокси на клиенте.

Далее надо получить IObserver:

public static IObserver<Unit> CreateQueueNotifierObserver(this IQueueNotifier proxy, string queueName)
{
    return Observer.Create<Unit>(
                _ => proxy.MessageAdded(queueName),
                _ => proxy.NoMoreMessages(queueName),
                () => proxy.NoMoreMessages(queueName)
            );
}

Надо помнить что экземпляров воркера может быть много и у вас получится по одному наблюдателю на каждый инстанс воркера. При этом не надо передавать оповещение каждому воркеру, достаточно передать оповещение одному (случайному). В случае высокой нагрузки оповещения будут распределяться равномерно межу воркерами и никто их них не будет “спать”. В случае низкой нагрузки просыпаться будет только один воркер, экономя деньги.

public static IObserver<Unit> CombineObservers(List<IObserver<Unit>> notifiers)
{
    var rnd = new Random();

    return Observer.Create<Unit>(
            u => notifiers[rnd.Next(notifiers.Count)].OnNext(u),
            e => notifiers.ForEach(obs => obs.OnError(e)),
            () => notifiers.ForEach(obs => obs.OnCompleted())
        );
}

Обратите внимание что OnCompleted рассылается всем воркерам, чтобы можно было остановить обработку сообщений.

Остается только скомбинировать отправку сообщения в очередь с отправкой оповещения.

public static IObserver<CloudQueueMessage> ToObserver(this CloudQueue queue, IObserver<Unit> notifier)
{
    var addMessage = Observable.FromAsyncPattern<CloudQueueMessage>(queue.BeginAddMessage, queue.EndAddMessage);

    return Observer.Create<CloudQueueMessage>(
            m => addMessage(m).Subscribe(notifier.OnNext, notifier.OnError),
            notifier.OnError,
            notifier.OnCompleted);
}

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

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

Оптимизация процессинга в Windows Azure. Часть 1.

noreply@blogger.com (Станислав Выщепан) — Mon, 09 Jan 2012 06:00:00 +0000

Для тех кто не в курсе: Windows Azure – “облачная” платформа Microsoft. Создавая приложения, работающие “в облаке”, у вас есть возможность разделять систему на “роли”. Бывают веб-роли, которые представляют из себя обычные веб-приложения, бывают также worker-роли (далее воркеры), предназначенные для вычислений.

Для увеличения масштабируемости приложения используется очереди. Сообщения в очередях обрабатываются воркерами, а ставят сообщения чаще всего веб-роли или другие воркеры. Таким образом можно разбить какие-либо длительные операции на небольшие и обрабатывать их асинхронно на любом количестве узлов, так как очереди в Windows Azure специально проектировали для сценария множественных потребителей.

Типовой код для воркера Windows Azure на C# такой:

while (true)
{
    var msg = queue.GetMessage();
    if (msg != null)
    {
        //do some work
        queue.DeleteMessage(msg);
    }
    else
    {
        Thread.Sleep(10000);
    }

    Trace.WriteLine("Working", "Information");
}

Как вы думаете сколько стоит этот воркер. В смысле реальных денег потребляемых таким приложением, развернутым на Windows Azure.

Для этого надо посмотреть цены: https://www.windowsazure.com/en-us/pricing/details/.

Если задеплоить такую роль в одном small экземпляре, то получится $2,88 в день/$86,4 в месяц/~2600 рублей в месяц. Так? А вот и нет…

Есть еще “скрытая” стоимость такой архитектуры, заключается она в том что транзакции к хранилищу тоже оплачиваются https://www.windowsazure.com/en-us/pricing/details/#storage. Всего $0.01 за 10,000 транзакций. Каждая транзакция – это один запрос к azure storage.

Код выше выполняет один запрос каждые 10 секунд даже если нету никаких сообщений в очереди.
Стоимость такого кода получается 60*60*24*30/(10 * 1000) = $25,92 в месяц. вместе со стоимостью compute hours это выходит $112,32 в месяц. И это даже если код не выполняет никакой работы!

Кроме того SLA гарантирует работоспособность роли 99,95% только при наличии минимум двух инстансов, так что для устойчивости надо еще умножить цену на 2. Итого $250 в месяц.

Вывод

Архитектура, которую предлагает Microsoft для масштабирования довольно дорого стоит. Используйте код из примеров очень осторожно, он может увести ваш проект в большой минус.

Что делать?

Вариант первый – использовать service bus, в нем тоже есть очереди, но API позволяет в одной транзакции ожидать сообщения, а не сразу null возвращать при его отсутствии.

Вариант второй – использовать адаптивную подстройку интервала опроса очереди и выключать опрос в случае отсутствия сообщений.

Второй вариант кажется хорошей идеей так как позволяет масштабировать подход как “вниз”, так и “вверх”. Но тут возникает вопрос, а если мы прекратим прием сообщений, то как его потом возобновить? Видимо надо передать сообщение… Приходим снова к той же проблеме.

Но сигнал к “пробуждению” читателя сообщений можно передавать по более дешевому каналу, например через wcf internal endpoint.

Реализация

Чтобы абстрагироваться от всех деталей с сообщениями, таймаутами и каналами удобно использовать библиотеку Rx. Я использую Experimental версию так как в ней собрано много нужных комбинаторов.

Для начала надо вписать код в концепцию Rx. Длительные операции, вроде вызовов методов Cloud Storage и тайматуов сделать в виде IObservable.

public static IObservable<CloudQueueMessage> ObserveMessages(this CloudQueue queue)
{
    return Observable.Create<CloudQueueMessage>(obs => Iterator(obs, queue));
}

private static IEnumerable<IObservable<object>> Iterator(
                                                    IObserver<CloudQueueMessage> result, 
                                                    CloudQueue queue)
{
    //Observable queue.GetMessage
    var getMessage = Observable.FromAsyncPattern<CloudQueueMessage>(
                                        queue.BeginGetMessage,
                                        queue.EndGetMessage);
    //Observable queue.DeleteMessage
    var deleteMessage = Observable.FromAsyncPattern<CloudQueueMessage>(
                                        queue.BeginDeleteMessage,
                                        queue.EndDeleteMessage);

    while (true)
    {
        //var msg = queue.GetMessage();               
        var msgObs = getMessage().ToListObservable();
        yield return msgObs;
        var msg = msgObs[0];

        if (msg != null)
        {
            //do some work
            result.OnNext(msg);

            //queue.DeleteMessage(msg);                     
            yield return deleteMessage(msg).ToListObservable();
        }
        else
        {
            //Thread.Sleep(10000);
            //Same pattern as above
            yield return Observable.Timer(TimeSpan.FromSeconds(10))
                                   .ToListObservable();
        }

        Trace.WriteLine("Working", "Information");
    }
}

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

Функция вычисления таймаута:

private static TimeSpan CalulateDelay(int idleCount, int minimumIdleIntervalMs,  int maximumIdleIntervalMs, int deltaBackoffMs)
{
    // Calculate a new sleep interval value that will follow a random exponential back-off curve.
    int delta = (int)((Math.Pow(2.0, (double)idleCount) - 1.0) * (new Random()).Next((int)(deltaBackoffMs * 0.8), (int)(deltaBackoffMs * 1.2)));
    int interval = Math.Min(minimumIdleIntervalMs + delta, maximumIdleIntervalMs);

    // Pass the calculated interval to the dequeue task to enable it to enter into a sleep state for the specified duration.
    return TimeSpan.FromMilliseconds((double)interval);            
}

Честно украдена отсюда.

Сам код воркера:

var idleCount = 0;
while (true)
{
    var msgObs = getMessage().ToListObservable();
    yield return msgObs;
    var msg = msgObs[0];

    if (msg != null)
    {
        idleCount = 0;

        //do some work
        result.OnNext(msg);

        yield return deleteMessage(msg).ToListObservable();
    }
    else
    {
        var delay = 
                CalulateDelay(idleCount++, 
                              MinimumIdleIntervalMs, 
                              MaximumIdleIntervalMs, 
                              100);
        if (delay.TotalMilliseconds >= MaximumIdleIntervalMs)
        {
            yield break;
        }

        yield return Observable.Timer(delay).ToListObservable();
    }
}

Выключать цикл опроса сообщений мы научились, теперь попробуем научиться его включать. Будем считать что “внешний раздражитель”, который будет будить цикл выборки сообщений, выглядит как IObservable<T>.

public static IObservable<CloudQueueMessage> ObserveMessages<T>(
                                                this CloudQueue queue, 
                                                IObservable<T> haveMoreMessages)
{
    var iterator = Observable.Create<CloudQueueMessage>(
                                  obs => Iterator(obs, queue));
    IDisposable subscription = null;

    return Observable.Create<CloudQueueMessage>(
        obs => haveMoreMessages.Subscribe(
            _ =>
            {
                if (subscription == null)
                {
                    subscription = iterator.Subscribe(
                                                obs.OnNext, 
                                                obs.OnError, 
                                                () => subscription = null);
                }
            }, 
            () => subscription.Dispose() ));
}

Код получился запутанный, но при некоторой сноровке читается очень хорошо.

На сегодня все. В следующей части я расскажу как сделать пробуждение воркеров по сигналу и какими еще способами можно оптимизировать стоимость решения для Windows Azure.

Применимость DDD

noreply@blogger.com (Станислав Выщепан) — Mon, 12 Dec 2011 06:00:00 +0000

До сих пор не утихают холивары на тему DDD\rich vs anemic. С одной стороны апологеты DDD (domain driven design, дизайн на основе предметной области) твердят о том как это круто, с другой стороны говоря что оно не везде подходит. На вопрос где же оно подходит обычно затрудняются ответить или отвечают “for compex domain”, причем примеров применения такого встретить непросто.

Попробуем разобраться. Если отбросить всю философскую шелуху DDD, то придем к очень простой концепции жирной (rich, насыщенной) модели, описанной Фаулером. С одной стороны Фаулер предлагает поместить логику в классы “сущностей”, соответствующие данным предметной области. С другой стороны он прекрасно понимает что логика будет сложна и надо каким-то образом декомпозировать её. Кроме того есть логика, которая оперирует более чем одной сущностью и поместить её в один из классов сущностей не выгодно. Таким образом создаются классы сервисов, стратегий итп. Их всех объединяет свойство, что они не содержат данные предметной области и для работы обращаются к классам сущностей. По сути вся сложная логика располагается в этих самых сервисах.

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

Тут стоит отступить назад и посмотреть на общую картину. Как выглядит код приложения, использующий жирную модель (на основе модели в статье Фаулера):

class ContractsController
{
    public Result CalculateRecognitionsAction(int contractId)
    {
        var contract = repository.GetById(contractId);
        contract.CalculateRecognitions();
        repository.Save();
    }
}

Contract.CalculateRecognitions свою очередь выглядит как-то так:

public void CalculateRecognitions()
{
    this.Product.CalculateRecognitions(this);
}

А Product.CalculateRecognitions выглядит так:

public void CalculateRecognitions(Contract c)
{
    var recognitions = recognitionService.CalculateRecognitions(this);
    c.SetRecognitions(recognitions);
}

Теперь попробуем выполнить простое преобразование: на верхнем уровне будем вызывать сервис, а не методы сущностей.

class ContractsController
{
    public Result CalculateRecognitionsAction(int contractId)
    {
        var p = repository.GetProductByContractId(contractId);
        var recognitions = recognitionsService.CalculateRecognitions(p);
        repository.SaveRecognitionsForContract(contractId, recognitions);
    }
}

Такой код меньше по объему, имеет меньшую связность межу классами, от этого он более гибок и лучше подается оптимизации.

Сдвиг предмета моделирования

Если посмотреть какие концептуальные изменения произошли в коде в примере выше, то становится понятно что центральным объектом у нас стал RecognitionsService, а не Contract. То есть вместо модели исходных данных (предметной области) задачи мы начали использовать модель решения этой задачи. Модели исходных данных никуда не делась, просто её роль в решении стала гораздо меньше. Такая модель называется стройной (anemic).

Очевидно что модель решения задачи для решения задачи подходит лучше чем модель исходных данных задачи. Ведь моделировать экскаватор правильнее чем писать земля.Копайся() (спасибо за метафору Sinclair). Причем чем сложнее задача, тем выгоднее строить модель решения, а не исходных данных (предметной области).

Таким образом DDD не подходит для сложных задач.

Лирическое отступление

Если вы думаете что вынося всю логику из класса Product в ProductService\ProductHelper\ProductManager вы получаете модель решения, то вы жестоко ошибаетесь. Фактически это будет DDD, только в худшем его проявлении.

Сложные предметные области

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

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

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

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

Так где же область применимости DDD?

Как не удивительно, но DDD хорошо работает на простых задачах, там где нет необходимости разделять систему на слои, уменьшать связность путем выноса логики в отдельные стратегии итд. В простых задачах модель исходных данных (предметной области) и модель решения почти совпадают.

Например взять блог. Обычный блог как например этот. Моделью предметной области являются: блог, посты, комменты, страницы, виджеты в интерфейсе. Решение включает в себя функции: создать пост, изменить пост, удалить пост, получить список, поменять настройки блога. Все эти функции вполне можно поместить в класс Блога, а умный ORM разберется как потом все изменения положить в БД.

Но почему DDD столь популярен?

Именно потому что DDD хорошо работает на простых примерах. Ведь в книгах и презентациях невозможно привести пример на 20kloc. А на примерах в 100 строк DDD выглядит очевидно и очень привлекательно.

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

Заключение

Не стоит слепо следовать DDD. У догматичного DDD очень узкая область применения. Старайтесь моделировать решение задачи, не зацикливайтесь на моделировании исходных данных. Всегда оценивайте как то или иное решение повлияет на качество кода безотносительно DDD, ООП или других баззвордов.

В поисках неподвижной точки

noreply@blogger.com (Станислав Выщепан) — Mon, 21 Nov 2011 06:00:00 +0000

Наверное все знают что в C# 3.0 лямбда выражения, которые позволяют записывать анонимные функции (то есть функции без имени).
Например:

seq.Select(x => x * x);

Выражение x => x*x является функцией одного аргумента и возвращает значение квадрата числа.

А теперь попробуем записать функцию факториала:

Func<int, int> f = x => x > 1 ? x * f(x - 1) : 1;

Компилятор C# такое выражение не компилирует. Ругается на неинициализированную переменную f в правой части. Кстати roslyn такое прожевывает нормально. Тем не менее код выше не является выражением, его нельзя передать параметром в функцию.

Попробуем превратить его в выражение.

fact = f => x => x > 1 ? x * f(x - 1) : 1;

Тип выражения справа получится Func<Func<int,int>, Func<int,int>>, параметром передается рекурсивный вызов, чтобы его сформировать надо снова подставить рекурсивный вызов в функцию. Получится что-то вроде бесконечного вызова
fact(fact(fact(fact(…. но реально число вызовов конечно.

Немного теории

Для функций f которая принимает аргумент и возвращают значения из одного и того же множества (на C# это записывается как Func<T,T>, а в математике T –> T) может существовать “неподвижная точка” x, для которой f(x) = x. Чтобы находить неподвижные точки можно построить комбинатор g:(T->T)->T, такой что g(f) = x и f(x) = x. Функция g называется комбинатором неподвижной точки.

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

Краткая формула для рекурсивного комбинатора неподвижной точки Y выглядит как Y(g) = g(Y(g)). Если выполнить подстановку то получится g(g(Y(g))), выполняя подстановку бесконечное число раз получим как раз то что нам нужно для факториала.

Вернемся к практике

Попробуем написать на C#

static T Y<T>(Func<T, T> f)
{
    return f(Y(f));
}

Но язык C# использует энергичные вычисления и Y-комбинатор сразу попытается посчитать бесконечную рекурсию. Что приведет к StackOverflowException.

Ленивость вычислений как всегда вводится через лямбды.

static Func<T, T> Y<T>(Func<Func<T, T>, Func<T, T>> f)
{
    return x => f(Y(f))(x);
}

После этого вполне можно написать следующий код:

var fact = Y<int>(f => x => x > 1 ? x * f(x - 1) : 1);

Или например

seq.Select(Y<int>(f => x => x > 1 ? x * f(x - 1) : 1));

Таким образом получили возможность записывать анонимную рекурсию в виде выражения.

Заключение

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

Октябрьская встреча Russian SharePoint User Group

noreply@blogger.com (Станислав Выщепан) — Mon, 24 Oct 2011 15:17:00 +0000

Ссылка на анонс на сайте RUSUG: http://rusug.net/News/Lists/Posts/Post.aspx?ID=64

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

Настройка поиска SharePoint Server
Out-of-box возможности поиска
Кастомизация out-of-box функциональности
Использование серверного API поиска
Использование клиентского API поиска в sandboxed решениях
Архитектура поиска SharePoint Server

Все темы в пределах одного доклада не смогу рассказать, но 3-4 из них вполне могу пройти достаточно подробно.

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

Почему вам нужен SharePoint

noreply@blogger.com (Станислав Выщепан) — Mon, 17 Oct 2011 06:00:00 +0000

Последнее время на различных конференциях я слышу один и тот же вопрос:

А зачем мне нужен SharePoint?

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

Ниже “краткий” ответ, может быть вы найдете что-нибудь для себя.

Если вы руководитель или ИТ-директор компании более 5 человек и
- Используете MS Office
- Отправляете документы по электронной почте
- Использует расшаренные папки для хранения документов в электронном виде
- У вас есть процессы согласования и утверждения документов
- Храните данные в Excel или Access
- Хотите создать базу знаний
- Хотите развернуть helpdesk
- Пользуетесь средствами средствами Microsoft BI
- Хотите отображать данные из разных источников в одном месте
- Хотите развернуть корпоративный портал для сотрудников
если одно из вышеперечисленного верно, то вам однозначно нужен SharePoint. Он поможет вам создать единое хранилище документов и табличных данных с богатыми возможностями отображения и поиска. SharePoint позволяет создавать решения без среды разработки и написания кода. Продвинутые пользователи самостоятельно смогут создавать и улучшать решения в SharePoint.
Если вы менеджер проектов, то вам должны быть знакомы продукты MS Project и Project Server. Последний является надстройкой над SharePoint.
Но даже без Projet Server вы можете:
- Создавать отдельные сайты для проектов несколькими кликами мыши, где можно будет размещать и согласовывать документы
- Хранить и отображать на портале списки задач из Microsoft Project
- Отслеживать риски и проблемы
- При необходимости вывести создать на портале SharePoint интерфейс к другим системам управления проектами
- Получать сводку по вашим проектами
- Получать отчеты и KPI на портале
Если вы архитектор или ведущий разработчик и разрабатываете корпоративный софт, то вам нужен SharePoint потому что:
- он включает в себя возможности управления документами
- он имеет надежную систему разграничения доступа
- он интегрируется с MS Office
- он позволяет искать по всему содержимому
- он поддерживает длительные рабочие процессы, которые могут продолжаться больше чем время непрерывной работы серверов
- он имеет модульный пользовательский интерфейс
- он позволяет интегрироваться с другими системами
- он поддерживает масштабируемость всех своих компонент
- он почти весь функционал SharePoint поддается расширению и кастомизации
- содержит систему установки и удаления приложений, гораздо проще, чем написание инсталляторов вручную
Если вы IT-специалист, то вам обязательно нужен SharePoint. Он вам позволит:
- Собирать в одном месте данные из различных систем
- Отображать таблицы, графики, отчеты, KPI на портале
- Автоматизировать процессы процессы организации с помощью простых инструментов
- Размещать веб-контент не имея навыков веб-разработки
- Управлять множеством сервисов со сложной топологией с помощью простого графического интерфейса
- Заскриптовать любые действия с помощью PowerShell
Если вы рядовой .NET разработчик, то вы сможете в SharePoint:
- Применить уже имеющиеся навыки
  - для разработки интерфейса
  - для создания решений по интеграции с другими системами
  - для создания рабочих процессов
- Изучив платформу более детально вы сможете создавать любые решения и превратитесь из рядового разработчика в высокооплачиваемого специалиста :)
Если вы веб-разработчик, то ваши навыки будут очень востребованы в среде SharePoint
- для брендинга портала, это сейчас очень востребованная тема
- для разработки макетов веб-страниц для размещения контента
  (html + css + js)
- для создания представлений данных и результатов поиска
  (xslt + html + css + js)
- для приложений на javascript или silverlight, большая часть функциональности SharePoint доступна на клиентской стороне

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

Если у вас будут возникать вопросы по SharePoint , то присоединяйтесь с сообществу http://area51.stackexchange.com/proposals/35899/sharepoint-in-russian, поддержите его развитие и вы сможете получать много полезной информации.

Решение задач. Задача таймера, совсем конец.

noreply@blogger.com (Станислав Выщепан) — Fri, 14 Oct 2011 06:00:00 +0000

Посты в этой серии:

Список задач для проверки навыков.
Создание задачи таймера.
Использование подходящих классов.
Передача команд задаче таймера.
Взаимодействие веб-фронтэнда с задачами таймера (этот пост).

В прошлом посте был показан способ создать worker, который будет получать сообщения от frontend и обрабатывать их.

Теперь необходимо придумать как оправлять эти сообщения. В 2010 есть почти универсальный способ для размещения функционала – Ribbon. Даже если у вас возникает непреодолимое желание сделать ссылку\кнопку\пункт меню в другом месте, то скорее всего для целей usability надо будет повторить его в ribbon.

Для того чтобы добавить кнопку в ribbon надо создать custom action, я для этого использую cks:dev. Руководство по расширению риббона можно найти как на MSDN, так и в блогах глубоко уважаемых людей (надеюсь меня не забанят за такое количество ссылок).

Мой код получился такой:

<CustomAction Id="CleanupLibraryButton"
              Title="Cleanup"
              RegistrationType="List"
              RegistrationId="101"
              Location="CommandUI.Ribbon">
  <CommandUIExtension>
    <CommandUIDefinitions>
      <CommandUIDefinition Location="Ribbon.Library.Settings.Controls._children">
        <Button Id="Ribbon.Library.Settings.Cleanup"
                Command="CleanupLibraryCommand"
                TemplateAlias="o2"
                LabelText="Cleanup"
                Sequence="100"
                Image16by16="/_layouts/images/warning16by16.gif"
                Image32by32="/_layouts/images/CRIT_32.GIF"                   
                />
      </CommandUIDefinition>
    </CommandUIDefinitions>
    <CommandUIHandlers>
      <CommandUIHandler Command="CleanupLibraryCommand" 
                        CommandAction="???"/>
    </CommandUIHandlers>
  </CommandUIExtension>
</CustomAction>

Немного громоздко, но если разобраться в схеме, то довольно очевидно. Кнопка добавляется в последнюю группу кнопок на закладке “Билиотека”.

Теперь самый интересный вопрос, что написать в CommandAction, где я в схеме поставил вопросы.

Самый прямолинейный способ – указать ссылку на application page, который вызовет site.AddWorkItem, но это кардинально противоречит самой идее ribbon.

SharePoint 2007 way

В SharePoint 2007 часто применялся delegate control, и действия в интерфейсе выполняли postback, а этот самый контрол обрабатывал форму и производил действия.

Для начала добавлю еще один cutom action с location равным ScriptLink. В таком custom action можно размещать ссылку на javascript или блок кода, который будет выведен на каждой странице.

<CustomAction 
    Location="ScriptLink"
    ScriptSrc="~site/_layouts/CleanupTimerJob/script.js" />

Команда для ribbon будет выглядеть так:

<CommandUIHandler 
    Command="CleanupLibraryCommand" 
    CommandAction="javascript:submitLibraryToCleanup()"/>

В самом же js файле будет простой код:

function submitLibraryToCleanup() {
    var listId = SP.ListOperation.Selection.getSelectedList();
    if (listId) {
        __doPostBack('CleanupPostBackEvent', listId);
    }
}

SP.ListOperation.Selection – класс, позволяющий получать данные о текущем представлении списка. Представлений списка на странице может быть больше одного, а ribbon – один.

Функция __doPostBack создается веб-формами, в первом параметре обычно указывается id элемента управления, которому адресуется postback, а во втором передаются параметры. Но узнать id нашего delegate control (который будет ниже) не представляется возможным, поэтому требуется заранее определенная константа и ручной анализ в теле контрола.

Сам контрол:

[Guid("0a3b8df1-0a43-485d-be83-983c1df8b30d")]
public class PostbackHandler : WebControl
{
    protected override void OnLoad(EventArgs e)
    {
        if (this.Page.Request["__EVENTTARGET"] == Constants.CleanupPostBackEvent)
        {
            var listId = new Guid(this.Page.Request["__EVENTARGUMENT"]);
            var web = SPContext.Current.Web;
                            
            SPSecurity.RunWithElevatedPrivileges(() =>
                {
                    using (var site = new SPSite(SPContext.Current.Site.ID))
                    {
                        site.AddWorkItem(
                            new Guid(), DateTime.UtcNow, Constants.WorkItemType,
                            web.ID, listId, -1,
                            true, new Guid(), web.ID,
                            web.CurrentUser.ID, null, null, new Guid());
                    }
                });
        }
    }
}

Основное внимание стоит уделить функции AddWorkItem. Во-первых её необходимо вызывать с правами администратора семейства сайтов, иначе будет ошибка. Во-вторых при указании времени доставки WorkItem необходимо указывать время в формате UTC. В-третьих, даже если не используются параметры listItemId и userId, то все равно надо указывать ненулевые значения иначе SharePoint попытается записать в базу null, что приведет к ошибке так как эти поля not null. И в-четвертых лучше всего указывать batchId, такой же как у webId, если нет других соображений. Судя по документации msdn и реализации TimerJobUtility это может сэкономить ресурсы.

Чтобы ваш delegate control заработал необходимо добавить элемент в фичу. Здесь также поможет cks:dev, в нем уже есть шаблон.

<Control Id="AdditionalPageHead" 
         Sequence="1000" 
         ControlAssembly="$SharePoint.Project.AssemblyFullName$" 
         ControlClass="$SharePoint.Type.0a3b8df1-0a43-485d-be83-983c1df8b30d.FullName$" />

Но сразу после развертывания этого элемента контрол не заработает, нужно еще добавить класс в safecontrols в web.config. Ни в коем случае не надо писать модификацию конфига самостоятельно, для этого уже есть инструменты в студии.

Ну вот и все…

SharePoint 2010 way

Если сделать как написано выше, то нажатие на кнопку приведет к постбеку, то есть перезагрузке всей странице. Хотя, учитывая архитектуру, пользователь сразу не увидит изменений в любом случае. Поэтому необходим ajax, обязательно с feedback пользователю.

Для этого нужно сделать: веб-сервис в sharepoint, который обработает запрос и поменять script.js, чтобы он вызывал этот веб-сервис.

Чтобы сделать веб-сервис снова нужно воспользоваться cks:dev с готовым шаблоном. В готов шаблоне надо поменять в svc файле тип фабрики с MultipleBaseAddressBasicHttpBindingServiceHostFactory на MultipleBaseAddressWebServiceHostFactory чтобы можно было вызывать методы сервиса из js.

Выкинув все лишнее можно получим до безобразия простой сервис:

[Guid("36471285-d168-49ea-b191-6c83cfe1fe3e")]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
[ServiceContract]
public class CleanupService
{
    [OperationContract]
    [WebInvoke(
        UriTemplate = "/SubmitLibraryToCleanup({listId})",
        BodyStyle = WebMessageBodyStyle.Bare,
        RequestFormat = WebMessageFormat.Json,
        ResponseFormat = WebMessageFormat.Json)]
    public void SubmitLibraryToCleanup(string listId)
    {
        CleanupUtility.AddCleanupWorkitem(SPContext.Current.Web, new Guid(listId));
    }
}

Как видите, большую часть сервиса занимают атрибуты. Метод вызывается с помощью POST, параметры передаются прямо в строке запроса.

Далее необходимо в script.js файле поправить метод submitLibraryToCleanup чтобы он вызывал веб-сервис.

ВНИМАНИЕ. Приведенный далее код работает, но крайне не рекомендую использовать его в своих решениях. Используйте более человеческие библиотеки, вроде jQuery.

function submitLibraryToCleanup(isOldSchool) {
    var listId = SP.ListOperation.Selection.getSelectedList();
    if (listId) {
        var notification = null;
        var request = new Sys.Net.WebRequest();
        request.set_url(GetWebUrl() + "_vti_bin/CleanupTimerJob/CleanupService.svc/SubmitLibraryToCleanup("+listId+")");
        request.set_httpVerb("POST");
        request.add_completed(function(executor, eventArgs) {
            SP.UI.Notify.removeNotification(notification);
            SP.UI.Notify.addNotification("Done",false);
        });             
        notification = SP.UI.Notify.addNotification("Submitting library to cleanup",true);
        request.invoke();
    }
}

Этот код использует так называемую Microsoft Ajax Library для выполнения запроса на сервер, и методы Client OM SharePoint для отображения оповещений.

Функция GetWebUrl скопирована отсюда.

Заключение

Надеюсь вы все таки дочитали до сюда и узнали что-то новое. Весь код можно найти на spsamples.codeplex.com

Решение задачи. Задача таймера, почти конец.

noreply@blogger.com (Станислав Выщепан) — Thu, 13 Oct 2011 06:00:00 +0000

Посты в этой серии:

Список задач для проверки навыков.
Создание задачи таймера.
Использование подходящих классов.
Передача команд задаче таймера (этот пост).
Взаимодействие веб-фронтэнда с задачами таймера.

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

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

Надо как-то ограничить задачу таймера чтобы она бегала только по тем сайтам где разрешит администратор.

Проще всего этого добиться создав фичу уровня Web, которая выставляет свойства узла при активации и модифицировать задачу таймера, чтобы она проверяла свойство.

Код Feature Receiver

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    SetCleanupFlag(properties, true);
}

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
    SetCleanupFlag(properties, false);
}

private void SetCleanupFlag(SPFeatureReceiverProperties properties, bool flag)
{
    var web = properties.Feature.Parent as SPWeb;
    web.Properties[Constants.FlagPropertyName] = flag.ToString();
    web.Properties.Update();
}

Изменения в Timer Job:

private void ProcessWeb(SPWeb web)
{
    if (Convert.ToBoolean(web.Properties[Constants.FlagPropertyName]))
    {
        tju.ProcessLists(web.Lists, ProcessList, null);
    }
}

Вот теперь задача таймера будет обрабатывать только то что укажет администратор. Для своих задач передачи данных из контекста веб-приложения в timer job вы можете также использовать списки, лучше скрытые.

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

WorkItems

Про механизм “очередей” в SharePoint я писал ранее, но тогда не было подходящей задачи для иллюстрации.

Используем простую идею: некоторое действие пользователя ставит в очередь задачу (SPWorkItem), а задача таймера (worker) анализирует очередь на наличие новых задач и обрабатывает их.

Для создания worker необходимо создать класс наследник SPWorkItemJobDefinition, в котором переопределить два метода WorkItemType и ProcessWorkItem. Документация на MSDN утверждает что вам необходимо переопределить один из методов ProcessWorkItems (с буквой s в конце) – не верьте.

При обработке work item есть много тонкостей, но я не буду их тут описывать, а просто использую уже знакомый класс TimerJobUtility, в котором уже сделана вся “грязная” работа.

public class CleaupWorker : SPWorkItemJobDefinition
{
    TimerJobUtility tju;
    WorkItemTimerJobState wiJobState = new WorkItemTimerJobState(true);

    public CleaupWorker() : base() { }

    public CleaupWorker(SPWebApplication webApp)
        : base(Constants.WorkerJobName, webApp)
    {
        this.Title = "Folder cleanup worker";
    }

    public override Guid WorkItemType()
    {
        return Constants.WorkItemType;
    }

    protected override bool ProcessWorkItem(SPContentDatabase contentDatabase, SPWorkItemCollection workItems, SPWorkItem workItem, SPJobState jobState)
    {
        tju = new TimerJobUtility(Constants.TimerJobName, jobState);
        return tju.ProcessWorkItem(workItems, workItem, wiJobState, ProcessWorkItemCore);
    }

    private void ProcessWorkItemCore(SPWorkItem wi, WorkItemTimerJobState timerJobstate)
    {
        var list = timerJobstate.Web.Lists[wi.ParentId];
        CleanupUtility.CleanupList(list);
    }
}

Тем, кто занимается разработкой для SharePoint Foundation повезло гораздо меньше, им придется все подводные камни обходить самостоятельно. Крайне рекомендую для этого посмотреть реализацию TimerJobUtility.

Чтобы поместить WorkItem в очередь необходимо вызывать метод SPSite.AddWorkItem. Остается самый интересный вопрос: где вызывать этот метод. Об этом, и многом другом в следующей статье.

Убрать левую панель в SharePoint

noreply@blogger.com (Станислав Выщепан) — Wed, 12 Oct 2011 13:48:00 +0000

Именно с этим вопросом ко мне обратились трое за последнюю неделю.

Сделать это довольно просто c помощью CSS

#s4-leftpanel
{
    display:none;
}

.s4-ca
{
    margin-left:auto;
}

Но вот где написать этот стиль…

Если вам нужно получить такой эффект на одной странице, то необходимо добавить в контент AdditionalPageHead.
Если нужно для всего сайта, то поправить MasterPage или CSS, который используется на мастер-странице.
Если нужно такое на странице веб-частей, то ничего не нужно делать. Уже существует шаблон страницы веб-частей где убрана левая панель.
Если нужно убрать левую панель во всей коллекции сайтов, то можно создать в корневом сайте файл и подключить его с помощью SPWeb.AlternateCssUrl. При включении фич публикации этой настройкой можно управлять из админки сайта.

Решение задачи. Задача таймера, продолжение.

noreply@blogger.com (Станислав Выщепан) — Tue, 11 Oct 2011 06:00:00 +0000

Список задач для проверки навыков.
Создание задачи таймера.
Использование подходящих классов (этот пост).
Передача команд задаче таймера.
Взаимодействие веб-фронтэнда с задачами таймера.

В прошлый раз я писал о том как создать задачу таймера в SharePoint. Такой код писать не нужно. Надеюсь никто не успел скопипастить код к себе в проект.

В SharePoint 2010 основной класс для создания задач таймера – SPPausableJobDefinition. В отличии от обычного SPJobDefinition, как вы можете догадаться из названия, SPPausableJobDefinition можно останавливать.

Чтобы создать приостанавливаемую задачу таймера надо переопределить метод Execute с параметром SPJobState. Объект класса SPJobState содержат как свойства, говорящие о том что задача должна остановиться, так и методы сохранения текущего состояния задачи таймера для продолжения работы.

С одной стороны возможность приостанавливать выполнение задачи таймера ведет только к усложнению кода, но нету необходимости писать код, он уже есть в сборке Microsoft.SharePoint.

Класс, который больше всего подходит к нашей задаче – SPAllSitesJobDefinition. Задачи таймера, наследующиеся от этого класса должны переопределить только один метод ProcessSite.

public class TimerJob : SPAllSitesJobDefinition
{
    public TimerJob()
        : base()
    {

    }

    public TimerJob(SPWebApplication webApp)
        : base(Constants.TimerJobName, webApp)
    {
        this.Title = "Folder cleanup job";
    }

    public override void ProcessSite(SPSite site, SPJobState jobState)
    {            
        foreach (SPWeb web in site.AllWebs)
        {
            try
            {
                ProcessWeb(web);
            }
            finally
            {
                web.Dispose();
            }
        }
    }

    private void ProcessWeb(SPWeb web)
    {
        //omited for clarity
    }
}

Кода получилось даже меньше чем в первом варианте, при этом он поддерживает приостановку и запуск с места остановки, а также обновляет значения прогресса выполнения (это новая фича SharePoint 2010).

В прошлом посте писал о выборе значения SPJobLockType. В SharePoint 2010 нет такой необходимости. Разные варианты запуска задач таймера реализованы разными классами в сборке Microsoft.SharePoint.
Например: SPContentDatabaseJobDefinition, SPFirstAvailableServiceJobDefinition, SPServerJobDefinition, SPServiceJobDefinition.

Далее можно модифицировать код ProcessSite и ProcessWeb чтобы поддерживать перезапуск задачи с конкретной библиотеки документов. Но если вы разрабатываете для SharePoint Server 2010 (платной версии), то вам и это не надо делать. Код уже написан.

TimerJobUtility

TimerJobUtility – класс из сборки Microsoft.Office.Server. Он позволяет обходить содержимое SharePoint учитывая возможность остановки и перезапуска задачи таймера.

С использованием TimerJobUtility методы будут выглядеть так:

TimerJobUtility tju;
public override void ProcessSite(SPSite site, SPJobState jobState)
{
    tju = new TimerJobUtility(Constants.TimerJobName, jobState);
    tju.DisableEventFiring = false;
    tju.CancellationGranularity = IterationGranularity.List;
    tju.ResumeGranularity = IterationGranularity.List;
    tju.ProcessSite(site, s => tju.ProcessSite(s, ProcessWeb, null));
}

private void ProcessWeb(SPWeb web)
{
    tju.ProcessLists(web.Lists, ProcessList, null);
}

private void ProcessList(SPList list)
{
    if (!list.Hidden && list is SPDocumentLibrary)
    {
        DeleteEmptyFolders(list.RootFolder.SubFolders);
    }
}

private void DeleteEmptyFolders(SPFolderCollection folders)
{
    //omited for clarity
}

С таким кодом в случае остановки и перезапуска задачи она продолжит выполнять начиная с того списка, который не был обработан. Кроме того есть возможность блокировать срабатывание обработчиков событий установкой флага DisableEventFiring.

SPFolderHierarchy

5000… Для всех разработчиков SharePoint 2010 это магическая цифра. Если у вас запрос должен обработать более 5000 строк, то выпадает SPQueryThrottledException. Причем даже если реально будет возвращено мало строк, но для их вычисления придется просмотреть более 5000 элементов, то будет ошибка. В таких случаях помогает индекс или постраничное разбиение.

Нетрудно догадаться что стандартная реализация свойства SubFolders считывает все элементы из папки, которых может оказаться более 5000., что вызовет ошибку. Чтобы обрабатывать такие случаи в SharePoint Server 2010 (платной версии) есть класс SPFolderHierarchy, который помогает избежать проблем и содержит множество эвристик для максимального быстродействия навигации по папкам.

В итоге, используя все вышеперечисленные возможности, код будет такой:

public class TimerJob : SPAllSitesJobDefinition
{
    TimerJobUtility tju;

    public TimerJob(): base() { }

    public TimerJob(SPWebApplication webApp)
        : base(Constants.TimerJobName, webApp)
    {
        this.Title = "Folder cleanup job";
    }

    public override void ProcessSite(SPSite site, SPJobState jobState)
    {
        tju = new TimerJobUtility(Constants.TimerJobName, jobState);
        tju.DisableEventFiring = false;
        tju.CancellationGranularity = IterationGranularity.List;
        tju.ResumeGranularity = IterationGranularity.List;
        tju.ProcessSite(site, s => tju.ProcessSite(s, ProcessWeb, null));
    }

    private void ProcessWeb(SPWeb web)
    {
        tju.ProcessLists(web.Lists, ProcessList, null);
    }

    private void ProcessList(SPList list)
    {
        if (!list.Hidden && list is SPDocumentLibrary)
        {
            DeleteEmptyFolders(new SPFolderHierarchy(list));
        }
    }

    private void DeleteEmptyFolders(SPFolderHierarchy h)
    {
        foreach (SPFolder folder in (h as IEnumerable<SPFolder>))
        {
            if (folder.Item != null)
            {
                DeleteEmptyFolders(h.GetSubFolders(folder.ServerRelativeUrl));
                if (folder.ItemCount == 0)
                {
                    folder.Delete();
                }
            }
        }
    }
}

Кроме повышенной надежности такого кода есть еще одно преимущество: классы TimerJobUtility и SPFolderHierarchy очень активно пишут диагностические сообщения в ULS. Таким образом вам гораздо будет легче отлаживать такой код на удаленной машине.

Решение задачи. Задача таймера.

noreply@blogger.com (Станислав Выщепан) — Mon, 10 Oct 2011 06:00:00 +0000

Список задач для проверки навыков.
Создание задачи таймера (этот пост).
Использование подходящих классов.
Передача команд задаче таймера.
Взаимодействие веб-фронтэнда с задачами таймера.

Ранее я приводил список задач для проверки навыков программирования для SharePoint. Сегодня напишу о решении четвертой задачи про задачу таймера для очистки библиотек документов от пустых папок.

Задача

Создать задачу таймера (Timer Job), которая буде находить в библиотеках документов пустые папки, в которых нет файлов и которые содержат пустые папки, и удалять их.

Класс задачи таймера

Чтобы создать задачу таймера необходимо создать класс, унаследованный от Microsoft.SharePoint.Administration.SPJobDefinition. Этот класс недоступен в sandbox, поэтому вам нужен farm solution.

В этом классе необходимо переопределить метод Execute и конструктор с параметрами.

public TimerJob(SPWebApplication webApp)
    : base(Constants.TimerJobName, webApp, null,
           SPJobLockType.ContentDatabase)
{
    this.Title = "Folder cleanup job";
}

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

Так как ферма SharePoint может состоять из нескольких серверов, то появляется интересный вопрос – где и сколько раз будет запускаться задача таймера. Особое внимание надо уделить параметру SPJobLockType. Детальное описание по ссылке. Возможные варианты:

SPJobLockType.ContentDatabase - задача таймера запускается для каждой контентной базы данных родительского приложения.
SPJobLockType.Job – задача таймера выполняется один раз на всю ферму. В данном режиме учитывается параметр SPServer конструктора, позволяющий указать конкретный сервер для запуска Timer Job.
SPJobLockType.None – запускается на каждом сервере в ферме, где развернут родительский сервис. Очень полезно если вам надо запустить некоторый некоторый процесс на каждом сервере в ферме.

Добавление и удаление задачи таймера

Для добавления задачи таймера удобно использовать фичу уровня фермы или веб-приложения с флагом Activate On Default равным true. При разветрывании решения с такой фичей она автоматически активируется в указанной области действия.

Код feature receiver:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    var webApp = properties.Feature.Parent as SPWebApplication;
    var job = new TimerJob(webApp);
    job.Schedule = new SPHourlySchedule()
    {
        BeginMinute = 0,
        EndMinute = 59
    };

    job.Update();
}


public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
    var webApp = properties.Feature.Parent as SPWebApplication;
    var job = webApp.JobDefinitions.GetValue<TimerJob>(Constants.TimerJobName);
    job.Delete();
}

Класс SPHourlySchedule является наследником SPSchedule и позволяет задавать расписание запуска задачи таймера.

Важно. Если вы попытаетесь добавить задачу таймера в фиче уровня Site или Web, то при деплое из Visual Studio оно сработает, а при попытке активировать фичу из веб-интерфейса упадет. Это новое ограничение SharePoint 2010, не позволяющее делать Update для классов наследников SPPersistedObject из контекста веб-приложения.

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

Обработка элементов списков

Теперь перейдем к основной функции задачи таймера – очистка папок.

public override void Execute(Guid targetInstanceId)
{
    SPWebApplication webApplication = this.Parent as SPWebApplication;
    SPContentDatabase contentDb = webApplication.ContentDatabases[targetInstanceId];

    ProcessDatabase(contentDb);
}

Так как при создании Timer Job был указан SPJobLockType.ContentDatabase, то в качестве параметра targetInstanceId будет ID базы данных контента.

Далее циклы по SPSite и SPWeb:

private void ProcessDatabase(SPContentDatabase contentDb)
{
    foreach (SPSite site in contentDb.Sites)
    {
        try
        {
            ProcessSite(site);
        }
        finally
        {
            site.Dispose();
        }
    }
}

private void ProcessSite(SPSite site)
{
    foreach (SPWeb web in site.AllWebs)
    {
        try
        {
            ProcessWeb(web);
        }
        finally
        {
            web.Dispose();
        }
    }
}

Вот такие конструкции необходимо использовать чтобы пройтись по всем SPSite и SPWeb в базе данных. Если не напишите Dispose в циклах, то на сервере очень быстро закончится память.

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

Для того чтобы обезопасить себя и ваших пользователей необходимо использовать утилиту SPDisposeCheck. Она вам подскажет где надо совободить объекты.

Ну и наконец удаление папок:

private void ProcessWeb(SPWeb web)
{
    foreach (var lib in web.Lists.OfType<SPDocumentLibrary>())
    {
        if (!lib.Hidden)
        {
            DeleteEmptyFolders(lib.RootFolder.SubFolders);
        }
    }
}

private void DeleteEmptyFolders(SPFolderCollection folders)
{
    foreach (var folder in folders.OfType<SPFolder>().ToList())
    {
        DeleteEmptyFolder(folder);
    }

}

private void DeleteEmptyFolder(SPFolder folder)
{
    if (folder.Item != null)
    {
        DeleteEmptyFolders(folder.SubFolders);

        if (folder.ItemCount == 0)
        {
            folder.Delete();
        }
    }
}

Не копипастите код из статьи до того как прочитаете следующую часть.

MVP

noreply@blogger.com (Станислав Выщепан) — Thu, 06 Oct 2011 21:58:00 +0000

Получил статус Microsoft MVP.

Теперь признанный кем-то эксперт и все такое.

Статьи про IoC, AOP и контейнер Unity

noreply@blogger.com (Станислав Выщепан) — Thu, 25 Aug 2011 06:00:00 +0000

Первые посты про IoC я написал более двух лет назад, но судя по статистике блога люди часто к ним обращаются.

В этом после приведу индекс статей в порядке чтения для облегчения поиска и навигации

SOLID

noreply@blogger.com (Станислав Выщепан) — Wed, 24 Aug 2011 06:00:00 +0000

Эта аббревиатура является самой известной (после ООП), она говорит нам о 5 принципах “хорошего дизайна ПО”. При этом является самой бесполезной, потому что однозначно никто не может обозначить критерий для того или иного принципа. Часто на форумах приходится видеть споры о том у кого программа SOLIDнее.

Про SOLID пишут часто и много, но большинство пишущих не читали или мало читали первоисточник (признайтесь, вы читали?). Автор аббревиатуры SOLID - Роберт Мартин, он придумал саму аббревиатуру и описал 5 принципов. На самом деле он описал больше, но звучных буквосочетаний не придумал, многие вещи остались забытыми. Заметьте что Мартин именно описал принципы, он не является их автором. Зачастую объяснения ~~на пальцах~~ на примерах сложно перенести в свой код.

Who is mister SOLID?

Аббревиатура (длинное и неприятное слово) SOLID состоит из:

Single Responsibility Principle (SRP) – принцип единственной отвественности
Open\Close Principle (OCP) – принцип открытости\закрытости
Liskov Substitution Principle (LSP) – принцип подстановки Лисков (это фамилия)
Interface Segregation Principle (ISP) – принцип изоляции интерфейсов
Dependency Inversion Principle (DIP) – принцип инверсии зависимостей

Далее буду пользоваться только акронимами, указанными в скобках.

Критика

Как связаны между собой вышеуказанные принципы никто не говорит, какой из них важнее, а какой нет – тоже никто не в курсе.

Разберем по отдельности все 5 принципов, для описания буду брать из википедии. Вероятнее всего именно это описание найдет человек.

SRP

На каждый объект должна быть возложена одна единственная обязанность.

Первое же определение взрывает мозг. Что такое обязанность? Мартин определяет обязанность как причину изменения. Стало понятнее? Мне не очень.

OCP

Программные сущности должны быть открыты для расширения, но закрыты для изменения.

Это как вообще? Открыты для расширения – еще куда ни шло, а что значит закрыты для изменения? Скомпилированный код и так поменять нельзя, а если правятся исходники, то какая разница?

LSP

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

Тут немного лучше, потому что принцип LSP предельно формален, про него подробнее напишу ниже.

ISP

Много специализированных интерфейсов лучше, чем один универсальный.

Это Мартин решил поиграть в Капитана Очевидность.

DIP

Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Это просто бред, написанный для красного словца. Если все зависит от абстракций, то как понять где модули верхнего уровня, а где нижнего?

У Мартина, кстати, не такое определение.

Терминология

Чтобы навести формализм во всей этой кухне необходимо ввести определения. большинство горячих споров происходят как раз из-за разных определений.

Итак определения

Интерфейс – некоторый набор функций (их параметров и возвращаемых значений), с помощью которого одна часть программы обращается к другой.

Контракт – надмножество интерфейса, описывающее также поведение функций, ограничения на входные\выходные параметры, инварианты, последовательность вызовов итд. Контракт обычно присутствует в программе неявно, но есть средства, позволяющие часть его описать явно. Например навороченные системы типов как в haskell, внешние средства вроде Code Contracts в .NET. Даже если контракт не определен явно, то в программе он неявно присутствует.

Абстрактный интерфейс – некоторый тип данных,состоящий из набора методов без реализации. Всегда соответствует некоторому интерфейсу.

Класс – некоторый тип данных, который состоит из данных и методов. Классы могут наследоваться один от другого, могут реализовывать несколько абстрактных интерфейсов. Класс всегда имеет некоторый интерфейс и контракт, зачастую больше одного.

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

Принципы

Для начала стоит сказать что многие принципы не являются прерогативой ООП, а применимы для широкого класса парадигм.

Начнем с SRP

Если часть некоторого модуля не имеет никаких ссылок на другую часть этого модуля, то эти части можно разделить на разные модули. Если модули могут меняться независимо, то разделить нужно.

Начинать стоит с простого: если можно отделить – надо отделить. Необходимо чтобы внутри одного модуля весь функционал был связан между собой (high cohesion, такое словосочетание вы наверное слышали). Принцип работает только в одну сторону: если подмножество A некоторого модуля не имеет ссылок на подмножество B, то это не значит что B не имеет ссылок на A, причем скорее всего именно B будет ссылаться на A.

Следуя данному принципу весь код будет распадаться на множество маленьких модулей, многие из которых выродятся до одной функции. Это нормально, даже хорошо. Функции потом можно группировать в модули по логической связности, добиваясь все того же high cohesion.

Модули будут зависеть друг от друга, они будут выстраиваться в ориентированный граф. Расположив зависимости сверху вниз можно условно разделить модули на верхне- и нижне- уровневые. На самом “пространство”, в котором мы пытаемся упорядочить модули, многомерно. Придумать одно отношение порядка для всего этого пространства невозможно. Но для двух модулей, между которыми есть путь, можно сказать какой из них верхнеуровневый, а какой нижнеуровневый.

Зависимость между модулями может быть:

Ссылочной, когда модуль A непосредственно обращается к модулю B, его функциям и данным.
Наследованием, когда модуль A является частным случаем B.
Зависимостью по состоянию, когда два модуля оперируют одним внешним состоянием (глобальные переменные, файлы, БД) и влияют на работу друг друга. Это плохая зависимость, от нее надо избавляться.
Зависимостью по времени. Когда для работы требуется одного модуля требуется вызов функций другого модуля в нужные моменты. Это самый плохой вид зависимости, он него надо избавляться однозначно всеми возможными способами.

Далее ISP

Как я уже писал выше, если следовать SRP, то программа распадется на множество мелких модулей. ISP говорит нам что это хорошо. Далее когда занимаетесь объединением отдельных функций в некоторые модули по смысловой связности, то учитывайте также ISP, не создавая модулей с очень жирным интерфейсом.

Перейдем к DIP

Этот принцип говорит нам что для двух ссылочно связанных модулей надо создавать абстрактный интерфейс. Оформлять модуль, от которого зависят другие модули, в виде класса, реализующего данный абстрактный интерфейс. Зависимый модуль должен обращаться к абстрактному интерфейсу, а не к конкретному классу. (low coupling, тоже слышали)

Есть проблема в том что надо создавать экземпляры классов, чтобы потом их передавать в зависимые модули. Эту проблему решают IoC-контейнеры, о которых я писал ранее.

Теперь рассмотрим LSP

Принцип подстановки Барбары Лисков сформулирован предельно формально и говорит вообще о любых типа, а не только классах ООП.

Если A является подтипом B, то в любом месте программы (функции), где требуется объект типа B, можно подставить объект типа A и поведение программы (функции) при этом не изменится.

В ООП если класс A унаследован от класса B, равно как класс A реализует абстрактный интерфейс B, то A является подтипом B, а B является супертипом A. Кроме того некоторые языки программирования поддерживают вариантность типов, для них тоже надо применять LSP, но там помогает компилятор.

Принцип LSP надо использовать максимально широко, надо ориентироваться на весь контракт, в том числе пред- и пост-условия, а также то что не описано в самой программе.

Для контрактов правила простые:

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

Напоследок OCP

Хорошо понимая LSP легко сообразить о чем говорит OCP.

Все не-sealed классы должны быть спроектированы таким образом, чтобы наследники не могли нарушить LSP.

Ну вот и все.

Что не вошло в пятерку

Принцип бритвы Оккма

Не плодите сущности без нужды

После активного применения SRP у вас будет много маленьких модулей, вплоть до одиночных функций. Тривиальные функции можно непосредственно инлайнить в вызывающий код, простые функции также можно перенести, если они используются только в одном месте. Отдельные функции можно объединять в модули по смысловому назначению, а также по параметрам, задавая их на уровне модуля, а не отдельных функций.

Do not repeat yourself (DRY)

Одинаковый или похожий код должен быть вынесен в отдельный модуль и использован другими. Для этого сильно помогают инструменты вроде IoC-контейнеров с возможностью AOP.

Command-Query Separation (CQS)

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

Пожалуйста не путайте этот принцип с модным нынче CQRS, который является гипертрофированным CQS для непонятно каких целей.

Keep it simple, stupid! (KISS)

Делайте все настолько простыми, насколько можно, но не проще.

Создавайте ровно те модули, которые необходимы для решения задач, если модуль не решает задачу – не создавайте его. Если вы хотите создать модуль, но толком не представляете какую задачу он решает – не создавайте его. Если при переделке программы модули стали ненужным – удалите их. Если в некоторых поведение системы не описано для некоторых входных данных - не делайте частные случаи, опишите явно контракт, который запретит неверные данные.

Заключение

Самыми важными принципами в начале проектирования частей программы являются KISS и SRP. После того как появился некоторый граф модулей надо сразу применять Бритву Оккама, LSP, ISP. Когда начинаете писать код, то применяйте DRY, DIP, CQS и OCP.

Ну вот теперь совсем все.

Решение задач. Соединенные веб-части, продолжение.

noreply@blogger.com (Станислав Выщепан) — Mon, 22 Aug 2011 06:00:00 +0000

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

План действий

Фильтрация в SPGridView
Оптимизация передачи данных между веб-частями
Добавление параметров для веб-частей
Асинхронная загрузка дерева
Bin deployment

Фильтрация в SPGridView

Разрабатывая UI на SharePoint мы имеем всю мощь библиотеки контролов ASP.NET, об этом не стоит забывать. Вместо того чтобы реализовывать функционал который уже есть лучше потратить время на изучение существующих возможностей.

Например можно перехватывать события SPGridView для обработки фильтрации, а можно использовать существующий инструментарий контролов Data Source для этих целей.

Подробно описано в статье, здесь приведу вкратце код для достижения цели.

Создание дочерних элементов веб-части:

this.ds = new ObjectDataSource(typeof(GridTableConsumer).AssemblyQualifiedName, "SelectData")
    {
        ID = "gridDS",
        EnableCaching = false
    };
this.ds.ObjectCreating += (sender, e) => e.ObjectInstance = this;
this.Controls.Add(this.ds);

this.grid = new SPGridView
    {
        ID = "grid",
        AutoGenerateColumns = false,
        DataSourceID = this.ds.ID,
        AllowFiltering = true,
        FilteredDataSourcePropertyName = "FilterExpression",
        FilteredDataSourcePropertyFormat = "{1} = '{0}'",
    };
this.Controls.Add(this.grid);

Для тех кто не знаком с классом ObjectDataSource рекомендую изучить его возможности. Для создания веб-частей очень хорошо подходит.

В данном коде применяется хитрость, чтобы контрол ObjectDataSource не создавал экземпляр класса, в данном случае веб-части, в обработчике события ObjectCreating подсовывается текущий экземпляр.

Далее метод SelectData

Чтобы работали фильтры SPGridView лучше всего возвращать объект DataTable.

IWebPartTable provider;
PropertyDescriptorCollection schema;
ICollection data;

public DataTable SelectData()
{
    EnsureDataAndSchema();

    DataTable result = null;
    if (this.data != null && this.schema != null)
    {
        result = this.data.ToDataTable(this.schema);
    }
    return result;
}

private void EnsureDataAndSchema()
{
    if (this.data == null)
    {
        this.provider.GetTableData((d, s) => 
        {
            this.data = d;
            this.schema = s;
        });
    }
}

В данном случае используется простые extension-метод GetTableData и ToDataTable. Их код можно посмотреть в исходниках.

Так как автоматически колонки для SPGridView не создаются, то необходимо это делать в коде, причем на наиболее позднем этапе жизненного цикла.

protected override void OnPreRender(EventArgs e)
{
    base.OnPreRender(e);

    EnsureDataAndSchema();
    GenerateGridColumns(this.grid, this.schema);
    this.grid.DataBind();
}

private static void GenerateGridColumns(SPGridView grid, PropertyDescriptorCollection properties)
{
    grid.Columns.Clear();
    if (properties != null)
    {
        var fields = properties.OfType<PropertyDescriptor>()
                               .Select(p => new SPBoundField
                               {
                                   DataField = p.Name,
                                   HeaderText = p.DisplayName,
                                   SortExpression = p.Name
                               })
                               .ToList();
        fields.ForEach(grid.Columns.Add);
        grid.FilterDataFields = string.Join(",", fields.Select(f => f.DataField).ToArray());
    }
}

Последняя строка в GenerateGridColumns необходима чтобы указать по каким колонкам можно фильтровать.

Ну собственно этого достаточно чтобы работала фильтрация в SPGridView. Все это выглядит как стандартное представление для списка.

Оптимизация

Теперь получается что веб-часть дерева организаций создает из профилей DataTable, передает его веб-части представления в виде таблицы и там еще раз создается DataTable. Можно оптимизировать и создавать таблицу один раз.

Мы можем передавать с помощью интерфейса IWebPartTable сам список сотрудников в выбранном подразделении, а в Schema передавать PropertyDescriptorCollection, которые позволят вытаскивать данные из профилей пользователей.

Для класса UserProfile таких дескрипторов нет, но никто не мешает их написать

public class UserProfilePropertyDescriptor: PropertyDescriptor
{
    public UserProfilePropertyDescriptor(ProfileSubtypeProperty propery)
        :base(propery.Name, new Attribute[] { new DisplayNameAttribute(propery.DisplayName)})
    {
    }

    public override bool CanResetValue(object component)
    {
        return false;
    }

    public override Type ComponentType
    {
        get { return typeof(UserProfile); }
    }

    public override object GetValue(object component)
    {
        return Convert.ToString((component as UserProfile)[this.Name].Value);
    }

    public override bool IsReadOnly
    {
        get { return false; }
    }

    public override Type PropertyType
    {
        get { return typeof(string); }
    }

    public override void ResetValue(object component)
    {
        throw new NotImplementedException();
    }

    public override void SetValue(object component, object value)
    {
        (component as UserProfile)[this.Name].Value = value;
    }

    public override bool ShouldSerializeValue(object component)
    {
        return false;
    }
}

Теперь нужно выкинуть код формирования таблицы, заменив его гораздо более простым

public void GetTableData(TableCallback callback)
{
    if (callback != null)
    {
        EnsureChildControls();
        if (this.tree.SelectedNode != null)
        {
            long recordId = 0;

            if (long.TryParse(this.tree.SelectedValue, out recordId))
            {
                var profiles = this.OrganizationProfileManager
                                   .GetOrganizationProfile(recordId)
                                   .GetImmediateMembers();
                callback(profiles);
            }
        }
    }
}

И в качестве Schema возвращать набор свойств профиля

public PropertyDescriptorCollection Schema
{
    get
    {
        if (this.schema == null)
        {
            var upm = new UserProfileManager(SPServiceContext.Current);
            //Filter section headers from property list
            var props = from prop in upm.DefaultProfileSubtypeProperties
                        where !prop.IsSection
                        orderby prop.DisplayOrder
                        select new UserProfilePropertyDescriptor(prop);
            this.schema = new PropertyDescriptorCollection(props.ToArray());
        }
        return this.schema;
    }
}

Параметры веб-частей

Веб-часть дерева организаций все время возвращает все свойства профиля, в реальном случае такой сценарий бесполезен. Надо научить веб-часть возвращать только нужные свойства.

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

[WebBrowsable(false)]
[Personalizable(PersonalizationScope.Shared)]
public string ProfileProperties { get; set; }

public HashSet<string> ProfilePropertyNames
{
    get
    {
        return new HashSet<string>((ProfileProperties ?? "").Split(new[] { PropertyNamesDelimeter }, StringSplitOptions.None));
    }
    set
    {
        ProfileProperties = string.Join(PropertyNamesDelimeter, value.ToArray());
    }
}

Атрибут WebBrowsable с параметром false говорит что не надо генерировать интерфейс для ввода параметра, а Personalizable говорит что значение этого свойствах надо хранить в свойствах веб-части.

Чтобы редактировать параметр нужен Custom Tool Part, сделать его довольно легко. Надо переопределить всего два метода, один для создания дочерних контролов, как у обычной веб-части, а второй для сохранения настроек.

public class OrganizationTreeToolPart : ToolPart
{
    ListBox list;
    public OrganizationTreeToolPart()
    {
        this.Title = "Profile properties";
    }

    protected OrganizationTree WebPart
    {
        get
        {
            return this.ParentToolPane.SelectedWebPart as OrganizationTree;
        }
    }

    protected override void CreateChildControls()
    {
        this.list = new ListBox()
        {
            SelectionMode = ListSelectionMode.Multiple,
            Height = Unit.Pixel(200)
        };
        var names = this.WebPart.ProfilePropertyNames;
        var upm = new UserProfileManager(SPServiceContext.Current);
        var items = from p in upm.DefaultProfileSubtypeProperties
                    where !p.IsSection
                    orderby p.DisplayOrder
                    select new ListItem(
                        string.Format("{0} ({1})", p.DisplayName, p.Name),
                        p.Name)
                        {
                            Selected = names.Contains(p.Name)
                        };
        this.list.Items.AddRange(items.ToArray());
        this.Controls.Add(this.list);
    }

    public override void ApplyChanges()
    {
        var set = new HashSet<string>(this.list
                    .GetSelectedIndices()
                    .Select(i => this.list.Items[i].Value));
        this.WebPart.ProfilePropertyNames = set;
    }
}

В этом Tool Part создается список с возможностью множественного выбора, который заполняется свойствами профилей пользователей.

Чтобы отображать этот Custom Tool Part необходимо веб-часть унаследовать от Microsoft.SharePoint.WebParts.WebPart и переопределить метод GetToolParts

public override ToolPart[] GetToolParts()
{
    var tps = base.GetToolParts().ToList();
    tps.Add(new OrganizationTreeToolPart());
    return tps.ToArray();
}

Далее чтобы использовать это свойство достаточно слегка изменить возвращаемую схему

public PropertyDescriptorCollection Schema
{
    get
    {
        if (this.schema == null)
        {
            var names = this.ProfilePropertyNames; //(1)
            var upm = new UserProfileManager(SPServiceContext.Current);
            //Filter section headers from property list
            var props = from prop in upm.DefaultProfileSubtypeProperties
                        where !prop.IsSection
                        where names.Contains(prop.Name) //(2)
                        orderby prop.DisplayOrder
                        select new UserProfilePropertyDescriptor(prop);
            this.schema = new PropertyDescriptorCollection(props.ToArray());
        }
        return this.schema;
    }
}

Изменения выделены комментариями.

Теперь пользователь сможет самостоятельно выбирать какие свойства профиля отправлять веб-части получателю.

Асинхронная загрузка дерева организаций по требованию

В первоначальном варианте дерево строилось при загрузке веб-части, но необходимости в этом нет. Достаточно построить дерево, из части узлов, а остальное загружать по требованию.

И снова нам на помощь приходит ASP.NET. Стандартный контрол TreeView умеет загружать узлы по требованию с помощь AJAX. Нам для этого надо сделать совсем мало:

Установить свойство TreeView.PopulateNodesFromClient = true
Указывать TreeNode .PopulateOnDemand = true, если требуется загрузка узлов по требованию
Обрабатывать событие TreeView.TreeNodePopulate, в обработчике которого и заниматься загрузкой узлов.

Код для загрузки по требованию

protected override void CreateChildControls()
{
    this.tree = new TreeView();
    this.tree.EnableClientScript = true;
    this.tree.PopulateNodesFromClient = true;
    this.tree.TreeNodePopulate += new TreeNodeEventHandler(tree_TreeNodePopulate);
    this.tree.Nodes.Add(ToTreeNode(this.OrganizationProfileManager.RootOrganization));
    Controls.Add(this.tree);
}


void tree_TreeNodePopulate(object sender, TreeNodeEventArgs e)
{
    var recordId = int.Parse(e.Node.Value);
    var profile = this.OrganizationProfileManager.GetOrganizationProfile(recordId);
    foreach (var child in profile.GetChildren())
    {
        e.Node.ChildNodes.Add(ToTreeNode(child));
    }

}

private static TreeNode ToTreeNode(OrganizationProfile child)
{
    return new TreeNode(child.DisplayName, child.RecordId.ToString())
           {
               PopulateOnDemand = child.HasChildren,
           };
}

Bin deployment

Сборки решений уровня фермы в SharePoint можно развертывать как в GAC, так и в каталог Bin веб-приложений SharePoint. Второй вариант подходит только для веб-частей, но в данном случае больше и не нужно.

Чтобы развернуть сборку в Bin надо поменять одну настройку в свойствах проекта

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

В результате в solution manifest (package) должен появиться раздел

<CodeAccessSecurity>
  <PolicyItem>
    <PermissionSet class="NamedPermissionSet" version="1">
      <IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" ObjectModel="True" />
      <IPermission class="SecurityPermission" version="1" Flags="Execution" />
      <IPermission class="AspNetHostingPermission" version="1" Level="Minimal" />
    </PermissionSet>
    <Assemblies>
      <Assembly
        Name="$SharePoint.Project.AssemblyName$"
        Version="$SharePoint.Project.AssemblyVersion$"
        PublicKeyBlob="$SharePoint.Project.AssemblyPublicKeyBlob$" />
    </Assemblies>
  </PolicyItem>
</CodeAccessSecurity>

Кстати SPSF генерирует переносы строк, но с ними не работает.

Заключение

Если вы дочитали до этого момента и ничего не поняли, то рекомендую более внимательно изучать ASP.NET Controls и .NET FW в частности компонентную модель, вопросы работы с данными и безопасностью, а также внимательно изучить ссылки, которые я привел в первом посте.

Исходный код можно найти на CodePlex: http://spsamples.codeplex.com/

Решение задач. Соединенные веб-части.

noreply@blogger.com (Станислав Выщепан) — Wed, 10 Aug 2011 03:00:00 +0000

Ранее я приводил список задач для проверки навыков программирования для SharePoint. Сегодня напишу о решении второй задачи про соединенные веб-части.

Задача

Создать веб-часть дерева организаций (подразделений)
Сделать её провайдером IWebPartTable
При выборе узла дерева веб-часть должна отправлять профили пользователей в организации
Создать веб-часть потребитель IWebPartTable с помощью SPGridView

Подготовка

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

Для решения задачи с соединенными веб частями понадобятся следующие ссылки:

Жизненный цикл веб-частей в SharePoint. Не уверен что сведения в этой статье точные, но они достаточно полные (помните правило: если о чем-то пишут, то не значит что оно так и работает).
Описание IWebPartTable. В конце статьи есть пример реализации, все довольно просто.
Описание SPGridView: часть 1, часть 2, часть 3, часть 4. Очень хорошая серия если будете использовать SPGridView в своих проектах.
Классы OrganizationProfileManager и UserProfileManager для работы с профилями.

Создание проекта

Выбираем Empty SharePoint Project, создаем его как Farm Solution

Добавляем две веб-части

По-умолчанию Visual Studio 2010 прописывает в .webpart файлах имена классов. это крайне неудобно, так как необходимо вручную править .webpart файлы при переименовании классов\изменении пространства имен.

Используя сведения отсюда, добавляем атрибуты классам веб-частей и изменяем .webpart файлы.

Создание дерева организаций

Для вывода дерева будем использовать контрол TreeView.

private TreeView tree;

protected override void CreateChildControls()
{
    this.tree = new TreeView();
    Controls.Add(this.tree);
}

Заполнение дерева организаций делается так:

protected override void OnLoad(EventArgs e)
{
    base.OnLoad(e);

    EnsureChildControls();
    var opm = new OrganizationProfileManager(SPServiceContext.Current);
    this.tree.Nodes.Clear();
    AddChildNodesRecursive(tree.Nodes, opm.RootOrganization);
}

private void AddChildNodesRecursive(TreeNodeCollection treeNodeCollection, 
                                    OrganizationProfile organizationProfile)
{
    var node = new TreeNode(organizationProfile.DisplayName, 
                            organizationProfile.RecordId.ToString());
    foreach (var child in organizationProfile.GetChildren())
    {
        AddChildNodesRecursive(node.ChildNodes, child);
    }

    treeNodeCollection.Add(node);
}

Те кто много писал кода для asp.net webforms сразу пытаются написать в методе OnLoad что-то вроде

if(!this.Page.IsPostBack)
{
    //....
}

Такой код верный если контрол находится в разметке страницы и его метод OnLoad выполняется при первой загрузке страницы. Для веб-частей в общем случае это неверно. Веб-части могут быть добавлены на страницу после её первой загрузки и код внутри if не выполнится. В таких случаях рекомендую анализировать состояние контролов и выполнять загрузку по необходимости. Но об этом в следующих постах.

Провайдер IWebPartTable

Чтобы создать веб-часть провайдер вам необходимо в классе веб-части определить метод, который возвращает интерфейс соединения и пометить его атрибутом.

[ConnectionProvider("Users")]
public IWebPartTable SendUsersFromSelectedNode()
{
    return this;
}

Название метода не имеет значения. Текст указанный в атрибуте используется в UI для формирования пункта меню, если создаете многоязычное приложение, то необходимо позаботиться о локализации. Сопоставление провайдера и потребителя осуществляется только по типу интерфейса.

Почти всегда методы провайдеров возвращают this, а необходимый интерфейс реализуется веб-частью. Таким образом методы интерфейса могут обращаться к состоянию веб-части для получения значений.

Теперь необходимо при запросе данных потребителем формировать некоторый объект, точнее коллекцию объектов (обычно используют DataTable) и схему этих данных в виде PropertyDescriptorCollection. Тут очень важны два момента:

Формировать данные при запросе потребителем, а не при изменении состояния веб-части. Многие, кто выполнял данную задачу, пытались перехватывать событие дерева об изменении выбранного узла, формировали DataTable и записывали в поле класса. Естественно после PostBack значение терялось. А если попытаться сохранить эти данные во ViewState, то начнет пухнуть страница.
Формировать данные только тогда, когда потребитель запросит их, потому что веб-части могут быть не соединены и работа будет делаться впустую.

private DataTable usersTable;

public void GetTableData(TableCallback callback)
{
    if (callback != null)
    {
        EnsureUsersTable();
        if (this.usersTable != null)
        {
            callback(this.usersTable.DefaultView);
        }
    }
}

public PropertyDescriptorCollection Schema
{
    get 
    {
        EnsureUsersTable();
        if (this.usersTable != null && this.usersTable.Rows.Count > 0)
        {                    
            return TypeDescriptor.GetProperties(this.usersTable.DefaultView[0]);
        }
        return null;
    }
}

Интефейс IWebPartTable не говорит о том в каком порядке будут вызываться члены Schema и GetTableData, поэтому для устойчивости решения необходимо поддерживать любой сценарий.

Сама загрузка данных происходит в методе EnsureUsersTable:

private void EnsureUsersTable()
{
    EnsureChildControls();
    if (this.usersTable == null)
    {
        if (this.tree.SelectedNode != null)
        {
            long recordId = 0;

            if (long.TryParse(this.tree.SelectedValue, out recordId))
            {
                this.usersTable = LoadOrganizationMembers(recordId);
            }
        }
    }
}

Приведенный выше код реализует паттерн Ensure\Create, который часто используется в asp.net webforms. Жизненный цикл страницы и контролов довольно сложен и может изменяться в зависимости от различных условий. Некоторые события могут не выполняться вообще, и поэтому необходимо удостовериться что данные загружены (Ensure).

Сам код LoadOrganizationMembers довольно очевидный. Первая часть метода формирует колонки DataTable, вторая часть метода заполняет строки DataTable.

private DataTable LoadOrganizationMembers(long recordId)
{
    var opm = new OrganizationProfileManager(SPServiceContext.Current);
    var org = opm.GetOrganizationProfile(recordId);

    var upm = new UserProfileManager(SPServiceContext.Current);

    //Filter section headers from property list
    var props = from prop in upm.DefaultProfileSubtypeProperties
                where !prop.IsSection
                orderby prop.DisplayOrder
                select prop;

    var columns = from p in props
                  select new DataColumn
                  {
                      ColumnName = p.Name,
                      Caption = p.DisplayName                              
                  };

    var result = new DataTable();
    result.Columns.AddRange(columns.ToArray());

    //Load profile properties to table
    foreach (var member in org.GetImmediateMembers())
    {
        var row = result.NewRow();
        foreach (var p in props)
        {
            row[p.Name] = Convert.ToString(member[p.Name].Value);
        }
        result.Rows.Add(row);
    }
    return result;
}

Обратите внимание на использование Convert, класс незаслуженно забытый программистами на C#. В SharePoint часто туда-сюда передаются object, которые могут быть внутри любыми типами. Наиболее устойчивый способ преобразовать к нужному типу – с использованием класса Convert. Данный класс выполняет приведение типов или парсинг в зависимости от типа входного значения, кроме того он наиболее корректно учитывает null.

Создание веб-части потребителя

Для создания веб-части потребителя требуется определить один метод и пометить его атрибутом

private IWebPartTable provider;

[ConnectionConsumer("Table")]
public void GetTableProvider(IWebPartTable provider)
{
    this.provider = provider;
}

Как и в случае с провайдером название метода не имеет значения, а текст в атрибуте используется в UI. Сопоставление производится по типу аргумента.

Далее создание контролов

protected override void CreateChildControls()
{
    this.grid = new SPGridView();
    grid.AutoGenerateColumns = false;
    this.Controls.Add(grid);
}

Как написано в статье, хорошее место для вызова методов получения данных от провайдера метод OnPreRender

protected override void OnPreRender(EventArgs e)
{
    base.OnPreRender(e);
    this.provider.GetTableData(d =>
    {
        if (d != null && d.Count > 0)
        {
            this.grid.DataSource = d;
            GenerateColumns(this.grid, this.provider.Schema);
            this.grid.DataBind();
        }
    });
}

Тут важно помнить что callback, переданный в GetTableData может быть не вызван вообще. Поэтому все действия по генерации колонок в гриде и связыванию с данными выполняются внутри callback.

Сам метод генерации колонок

private void GenerateColumns(SPGridView grid, PropertyDescriptorCollection schema)
{
    grid.Columns.Clear();
    if (schema != null)
    {
        foreach (PropertyDescriptor property in schema)
        {
            grid.Columns.Add(
                new SPBoundField 
                { 
                    DataField = property.Name, 
                    HeaderText = property.DisplayName, 
                    SortExpression = property.Name 
                });
        }
    }
}

Этого достаточно для вывода статической таблицы.

Суммарно весь код занимает не более 100 строк с точки зрения Visual Studio. Его вполне можно написать за час.

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