Sharepoint .BY SharePoint weblog, in Russian and English

SharePoint 2010 Dev Ignite: итоги

Введение.

Итак, давно запланированная статья по горячим следам SharePoint 2010b2 тренинга от Майкрософт. Рабочая неделя ушла на сидение в LiveMeeting, прислушиваясь к бодрой речи тренеров и клацая в виртуальной лабораторной. Если коротко – мне понравилось. Если подробнее – см. ниже.

Тренинг закончился недели 2 назад, однако написать о нем сподобился только сейчас, когда бурление идей в голове плавно перешло в задумчивое рассматривание идей, выстроенных на полочках в ней же. Самая интересная из них, на мой взгляд, это описать и показать смену ориентации Майкрософт с системы-в-себе на открытую и повернутую лицом к разработчикам платформу. Мой умозрительный вывод почти достиг грани парадокса – ASP .NET специалисту проще обучиться работе с SharePoint 2010, чем с SharePoint 2007! И более того, ASP .NET сблизился с SP2010 настолько, что разработчик ASP .NET воспримет идеи SP2010 чуть ли не легче, чем спец по SP2007. Однако мне не жаль годы, проведенные с WSS3 / MOSS2007, этот опыт пригодится и в двадцать-десять (заразился привычкой называть 2010 “twentyten” на конференции SPC2009  у местных докладчиков, ничего с собой поделать не могу теперь J ).

А теперь – к примерам.

SPLinq.

Что так шокировало моих коллег в процессе постижения WSS 3? Вообще-то много чего, но первым делом на ум приходит CAML. Иметь CAML Builder под рукой стало полезной привычкой, и конструкции вида

string simpleQuery = @"<Query><Where><Or><Eq><FieldRef Name=""ContentType"" />
<Value Type=""Text"">My Content Type</Value></Eq><IsNotNull><FieldRef Name=""Description"" />
</IsNotNull></Or></Where><GroupBy Collapse=""TRUE""><FieldRef Ascending=""FALSE""Title"" />
</GroupBy><OrderBy><FieldRef Name=""_Author"" /><FieldRef Name=""AuthoringDate"" />
<FieldRef Ascending=""TRUE""AssignedTo"" /></OrderBy></Query>";

почти не режут глаз. Но вот пришла Бета2, и мы с трепетом пишем заветный SPLinq:

var simpleQuery = from item in entitiesContext.Items

where item.Project.DueDate < DateTime.Now.AddYears(5)

orderby item.Project.DueDate

select new { item.Title, Contact =

item.Project.PrimaryContact.Title };

Кстати, теперь имеют место быть операции Join над листами прямо в SPLinq, поддерживаемые объектной моделью SP2010 (SPQuery.Join and SPQuery.ProjectedFields)! CAML-версия запросов с JOIN:

SPList list = siteCollection.RootWeb.Lists["Products"];

SPQuery query = new SPQuery();

query.Query = "<Where><Eq><FieldRef Name=\"Company\" /><Value

Type=\"Text\"/>Dell</Value></Eq></Where>";

query.Joins = "<Join Type=\"INNER\" List='" +

siteCollection.RootWeb.Lists["Companies"].ID + "' Alias=\"CMP\">

<Eq><FieldRef Name=\"Company\" RefType=\"ID\" /><FieldRef List=\"CMP\"

Name=\"ID\" /></Eq>

</Join>";

query.ProjectedFields = "<Field Name=\"CompanyHQ\" Type=\"Lookup\" List=\"CMP\"

ShowField=\"Headquarters\" />";

query.ViewFields = "<FieldRef Name=\"Title\" /><FieldRef Name=\"CompanyHQ\" />";

SPListItemCollection results = list.GetItems(query);

foreach (SPListItem item in results){

Console.WriteLine("{0} - {1}", item["Title"].ToString(), item["CompanyHQ"].ToString());

}

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

Некоторые нововведения коснулись традиционных для SP2007 узких мест – клиентских скриптов (и соответственно Ajax), и повторного использования кода.

Client Object Model.

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

Сейчас у нас есть Client Object Model, унифицированный API для работы на стороне клиента – будь то javascript, Silverlight, Forms .NET или ADO .NET клиент.

function getUserInfo(userID) {

var clientContext = new SP.ClientContext.get_current();

var web = clientContext.get_web();

var userInfoList = web.get_siteUserInfoList();

var camlQuery = new SP.CamlQuery();

camlQuery.set_viewXml('<View><Query><Where><Eq><FieldRef Name=\'ID\'/>' +

'<Value Type=\'Number\'>' + userID + '</Value></Eq>' +

'</Where></Query><RowLimit>1</RowLimit></View>');

this.collListItem = userInfoList.getItems(camlQuery);

clientContext.load(collListItem);

clientContext.executeQueryAsync(

Function.createDelegate(this, this.onQuerySucceeded),

Function.createDelegate(this, this.onQueryFailed));}

Эту функцию с минимальными изменениями можно использовать в любом из поддерживаемых клиентов, получая данные о профиле выбранного пользователя. Достаточно очевидно, и одинаково ново как для бывалого разработчика SharePoint 2007, так и для пришедшего с ASP .NET проекта молодого специалиста (не считая CAML, который пока удерживает последние рубежи в СОМ, но надеюсь это ненадолго).

Event Model.

Вероятно, оценив количество функционала, реализованного с помощью Event Receiver, в SharePoint 2010 парни из Майкрософт представили расширенную модель обработчиков событий. Теперь используя только ее можно настроить платформу под свои нужды, не утруждая себя подробным изучением других фич. Надеюсь однако, это не остановит вас от дальнейшего изучения возможностей SharePoint2010.

Custom Service Applications.

На первый взгляд не очень понятно, где можно применить этого зверя. Разработчики компании Майкрософт проделали тут большую работу, сделав прежние Shared Services расширяемыми и более гибко управляемыми, но не все смогут это оценить. Однако для реализации некоторых специальных требований это будет очень ценным инструментом. Своя служба поиска, общие для нескольких приложений ресурсы, глубокая интеграция со сторонними приложениями – в этих областях были наибольшие трудности в SharePoint 2007, и где теперь есть стандартная сбалансированная архитектура d SharePoint 2010.

Application Lifecycle Management.  Sandboxed Solutions.

Более очевидным стало управление жизненным циклом приложения. Кто сталкивался с необходимостью обновления пользовательского приложения SharePoint 2007 до новой версии, тот уже догадался, к чему я клоню. Основным сценарием до сих пор является «снес все старое, поставил все новое».

Теперь же есть официальные рекомендации производителей и, самое главное, средства это реализовать –

• версионность решений,
• скрипты, выполняемые в зависимости от того, с какой версии происходит обновление,
• переносимые и изменяемые файлы решений (WSP), теперь являющиеся также шаблонами(!)
• sandboxed solutions – и вам не надо ругаться с IT-службой, расследующей очередное падение фермы из-за неудачной  веб части, захватившего все ресурсы системы.

public override void FeatureUpgrading(SPFeatureReceiverProperties properties,

string upgradeActionName,

System.Collections.Generic.IDictionary<string, string> parameters) {

#if (DEBUG)

//To support debugging more efficiently

System.Diagnostics.Debugger.Launch();

#endif

// Check to see what upgrade action is being performed

if (upgradeActionName.Equals("MyCustomAddSiteColumnAction") == true) {

//Do the work

}

}

Visual Web part. Silverlight.

Знакомому с ASP .NET также естественным покажется поддержка Visual Part, появившаяся в SP2010. А вот знакомому с SharePoint 2007 это покажется неестественным.

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

Search.

Расширение поиска теперь тоже приблизилось к тому, как это должно было быть сделано изначально. С одной стороны, понятно, что Майкрософт очень заботит устойчивость и стабильность их продукта, но запечатывать классы (“sealed”), делая невозможным использовать наследование – явно не оптимальный выход. И вот их распечатали!

public class CoreResultsWithRankingModelID : CoreResultsWebPart {

QueryManager qm;

protected override XPathNavigator GetXPathNavigator(string viewPath) {

try {

qm = SharedQueryManager.GetInstance(this.Page).QueryManager;

qm.UserQuery = " scope:Important Tasks";

foreach (LocationList ll in qm) {

foreach (Location l in ll) {

try { l.RankingModelID = "c978ef2b-300a-444b-af9a-d51261294587"; }

catch { }

}

}

}

catch { }

return base.GetXPathNavigator(viewPath);

}

}

Branding.

Не так много изменений здесь, но одно из интересных – теперь Content Pages и Application Pages имеют общий Master Page.  Разработчики, пытавшиеся провести полное переоформление портала оценят это изменение. Традиционный Application.master был немного… как бы это сказать… недо-документирован. Теперь ситуация однозначно улучшится.

Development Tools.

На десерт – средства разработки. Интеграция с MS Visual Studio 2010, Powershell и обновленный и отшлифованный SharePoint Designer как три кита, на которых мы будем прочно стоять. Скажем спасибо и прощай верным WSPBuilder и SPVisualDev, однако некоторые open-source инструменты еще актуальны. Похоже, SharePoint Manager еще пригодится, и CAML Builder найдет себе применение в СОМ.

SharePoint 2007 Legacy.

А как же SharePoint 2007? Неужели все было так плохо, что Майкрософт был вынужден переделать всю платформу? Вовсе нет. Миграция  развернутых порталов и кода пока не без багов, но она есть, причем показательно, что миграция кода зачастую происходит простым переключением Target CPU на x64 или All CPU.  Особенно хорошо мигрируются проекты, выполненные с использованием VSeWSS,   которые кстати были прототипом SharePoint Development Tools  в MS Visual Studio 2010. Это должно повысить популярность расширений, которая значительно уступала многим community инструментам.

Многие Codeplex-проекты заблаговременно подготовились к выходу новой платформы и гордо выложили релизы “for SP 2010”.

Во многом прежними остались Web Parts (веб части – мне режет ухо, почему слово Parts перевели, а Web нет? J).

Learning.

Что же все-таки потребуется от программиста, желающего постичь все тонкости разработки на платформе SharePoint 2010? Во-первых, потребуется время. Несмотря на то, что сервисы построены на .NET Framework 3.5, IIS и SQL Server, они обзавелись богатой и развесистой объектной моделью, которую не мешало бы изучить.

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

Summary.

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

На месте .NET разработчиков, думающих о дальнейшем профессиональном развитии, я бы внимательно пригляделся к MS SharePoint Server 2010. По крайней мере, не соскучитесь!