Zprávy z Proffesional Developers Conference (PDC 2003)

Tomáš Tichý, zvláštní zástupce Intervalu v USA, vám přináší aktuální zpravodajství z Proffesional Developers Conference v Los Angeles. Každý den nové informace! (Den první – Longhorn, den druhý – Avalon, den třetí – Whidbey, den poslední – SQL Server Yukon a ObjectSpaces.)

Los Angeles nás přivítalo zataženou oblohou a nepříjemnými zprávami o rozsáhlých požárech v okolí města. Skutečně, v závislosti na větru se ovzduší plnilo kouřem a místní letiště bylo nuceno omezit provoz…

Den první: Longhorn (27. 10. 2003)

První den konference byl na programu keynote, kterou uváděli mimo jiné i známe tváře“ Bill Gates (viz záznam vystoupení), Jim Allchin a Don Box. Název úvodní prezentace „vlna Longhornu“ napovídá, o čem se převážně mluvilo. Longhorn má být nová generace operačního systému z dílen firmy Microsoft. Dle vyjádření pohlavárů je Longhorn přirovnáván k Windows 95 v době DOSu – má se tedy jednat nikoli o další verzi, ale o skutečně od základu přepracovaný operační systém. Přednáška a ukázky tomu odpovídaly, Longhorn přinese skutečné hodně změn.

Longhorn je z pohledu vývojáře nyní architektonicky rozdělen na tři základní kameny: vektorové grafické prostředí Avalon, souborový systém WinFS a komunikační základnu Indigo. Všechny tyto části budou v managed kódu a postupem času má být přístupná kompletní Win32 API v novém „managed“ aplikačním rozhraní s názvem WinFX. Staré aplikace poběží pořád pod Win32, čímž je zaručena zpětná kompatibilita. Z přednášky jsem se ale nedozvěděl, na jaké úrovni se budou obě rozhraní setkávat.

Avalon – Kompletně přepracované grafické uživatelské rozhraní. Hlavním rysem je vektorová definice formulářů a 3D povaha celého GUI. Rychlost je zaručena přímým zapojením grafického akcelerátoru. Důraz bude také kladen na alternativní vstupní rozhraní – psací pero, mluvenou řeč nebo dálkové ovládaní. Vektorové GUI se zdá být velice zajímavé, neumím si však představit, jak do Longhornu zapadá koncepce mobilních zařízeni – přeci jenom GeForce 4 nebude mít každý IPaq nebo Nokia. Možná se více dozvím v průběhu dalších přednášek.

WinFS – Sdílení dat mezi aplikacemi se zdá být hlavním rysem nového souborového systému. Ten má být založen na databázovém enginu Yukon a má umožnit propojení mezi aplikacemi na základě metadat, popisujících jednotlivé dokumenty. Opuštění standardní adresářové struktury umožňuje mít více pohledů na stejná data. Tyto „dotazy“ se pak vizuálně mohou chovat i jako standardní složky.

Indigo – V rámci Longhornu bude integrovaný peer-to-peer systém obsahující instant messaging, sdílení obrazovek (něco na styl remote desktop) a podporu pro synchronizaci klientů při ad-hoc připojení.

První veřejná beta verze má být k dispozici pro vývojáře v druhé polovině roku 2004. Vzhledem k rozsahu změn je pochopitelné, že konečný datum ještě nebyl přesně stanoven.

Den druhý: Avalon (28. 10. 2003)

Dnes bych se chtěl soustředit hlavně na nové grafické prostředí systému Longhorn – krycí jméno tohoto 3D vektorově orientovaného GUI je Avalon. Avalon by se dal z programátorského hlediska zjednodušeně popsat jako hybrid mezi ASP.NET a WinForms. Koncept codebehind je nyní uplatněn i na Longhorn Formsy – nový jazyk XAML (XML Application Markup Language) definuje elementy formuláře. Příklad jednoduchého formuláře se dvěma tlačítky může vypadat takto:

<NavigationWindow
  xmlns=“http://schemas.microsoft.com/2003/xaml“
  xmlns:def=“Definition“
  def:Class=“Viewer.Window1″
  def:CodeBehind=“Window1.xaml.cs“
  Text=“Prebuilt Viewer“ Visible=“True“
  Activated=“OnActivated“ Deactivated=“OnDeactivated“
  Loaded=“OnWindowLoaded“
  >
  <FlowPanel ID=“navBar“ DockPanel.Dock=“Top“ Width=“100%“ Height=“54px“ >
    <Button ID=“backButton“ IsEnabled=“False“ Click=“OnBackClicked“ Style=“{BackButton}“></Button>
    <Button ID=“forwardButton“ IsEnabled=“False“ Click=“OnForwardClicked“ Style=“{ForwardButton}“></Button>
  </FlowPanel>
</NavigationWindow>

CodeBehind soubor má pak za úkol, podobně jako v ASP.NET, obsluhovat logiku formuláře. Osobně považuji osamostatnění prezentace od kódu za velice prospěšnou, protože nyní může designer aplikace samostatně pracovat na grafickém návrhu. Kupříkladu firma Adobe prezentovala na keynote prezentaci plug-inu pro export do XAML.

Výhodou je také určité omezení „stupňů volnosti“ přesnou definicí schématu jazyka XAML. Dnešní designéry totiž fungují na principu analýzy kódu, který může často vést k různým nepředvídatelným událostem (určitě se vám již také podařilo párkrát shodit designer windows aplikace ve Visual Studiu .NET).Komu ovšem není XAML moc po chuti, může použit i „starý“ přístup, ve kterém komponenty ve formuláři vytváří za běhu.

Avalon má nyní podporovat širší možnosti databindingu pro všechny UI elementy. Velice příjemně mne opět překvapilo oddělení dat od prezentace při vázáni dat na GUI. Typický příklad – mějme třídu LegalCase popisující právnickou kauzu:

public class LegalCase: IPropertyChange {
public string Title {
get { ..}
set { ..}
}
public string CaseDescription{
get { ..}
set { ..}
}
…
}

Pomocí stylů můžeme definovat grafickou reprezentaci této třídy následovně:

<Style def:Name=“*typeof(LegalCase)“>
  <Style.VisualTree>
    <DockPanel Height=“100″ Margin=“10,10,5,0″>
      <Image DockPanel.Dock=“Left“ Width=“80″ Source=“images\stack256.png“/>
      <DockPanel Dock=“Fill“>
        <SimpleText DockPanel.Dock=“Top“ Text=“*Bind(Path=Title)“/>
        <SimpleText DockPanel.Dock=“Top“ Text=“*Bind(Path=CaseDescription)“/>
      </DockPanel>
    </DockPanel>
  </Style.VisualTree>
</Style>

Tento styl se v GUI použije všude, kde je zobrazována instance LegalCase – ať již to je v dropdownu comboboxu, v seznamu a nebo například v záhlaví formuláře.

Další přínos databindingu oproti předchozím verzím .NET frameworku je v konceptu CurrentItem. Jedná se o koncept, který je k vidění třeba u Delphi. Umožňuje například mít v DataGridu označenou jednu položku a ostatní prvky UI se budou vázat právě k této aktuálně vybrané položce – není tedy již nutné vytvářet obsluhu události pro změnu aktuálního prvku…

Pozn. red.: Jazyk XAML je obdobou XUL, v němž je definováno rozhraní Mozilly. Nejde o absolutní novinku, idea XAML sahá zpět až do roku 1997, k prvním definicím XML. Další informace viz též článek Create Real Apps Using New Code and Markup Model. Jedním z prvních praktických nasazení XAML má být uživatelské rozhraní připravovaného MSIE 7. (V této souvislosti není nezajímavá možnost automatizovaného převodu XUL na XAML prostřednictvím XSLT.)

Den třetí: ASP.NET Whidbey (29. 10. 2003)

Než přijde na scénu Longhorn, což se reálně odhaduje až za dva roky, vyplňuje Microsoft vývoj .NETu mezičlánkem s kódovým názvem Whidbey. Whidbey má být nová verze jak frameworku, tak Visual Studia a k celému balíku by se dal ještě připojit i nový SQL server Yukon. Pro lepší představu je na obrázku níže připojena mapa jmenných prostorů a tříd ve WinFX, což je API Longhornu, vycházející z dnešního .NET frameworku. Části označené písmenem „W“ mají být k dispozici již ve verzi Whidbey. Dobrou zprávou je, že Whidbey bude k dispozici již ve druhé polovině příštího roku.

mapa WinFX, 29. 10. 2003 (plná velikost, cca 300 kB)

Co nového tedy přináší Whidbey programátorům ASP.NET? Většina změn se tyká zjednodušení často používaných fukncí a postupů. Ti z vás, kteří si udělali vlastní frameworky pro personalizaci, skinování nebo cachování dat, mohou je rovnou vyhodit. Microsoft napříště nabízí tuto funkcionalitu v základní knihovně tříd. Ve Whidbey se znovu objeví i části „ztracené“ knihovny komponent IE WebControls (která přestala být podporována). Mezi nové komponenty patří například TreeView, Menu, SiteMap, DetailView, přepracovaný DataGrid a nebo CompositeControl pro jednodušší vytváření nových ASP.NET komponent.

Dodržení stejného layoutu mezi jednotlivými stránkami má napomoci MasterPage, což je vlastně šablona obsahující placeholder pro obsah jednotlivých stránek. ASP.NET zvládá na velice slušné úrovni management uživatelů a rolí i personifikaci obsahu na základě nastavení uživatele. Deklarativní obousměrný databinding pak odstraňuje nabdytečný kód pro parsování údajů z formuláře do vlastnosti objektu. Co se týče databindingu, celé Whitbey se poněkud odklání od konceptu DataSetů (i když tyto zůstávají nadále podporované) a doplňuje podporu pro libovolné objekty jako zdroje dat pro GUI. To sice šlo i v předchozích verzích, chyběla ovšem podpora v návrhovém režimu ve Visual Studiu. Mezi chuťovky též patří tzv. WebResources, umožňující použít pro resource stejného přístupu jako u formulářů Windows.

Pokud vás zajímají podrobnější informace, doporučuji vám navštívit stránky ASP.NET „Whidbey“.

Den poslední: SQL Server Yukon a ObjectSpaces (30. 10. 2003)

Na novou verzi databázového serveru již vývojáři čekají více než tři roky. Microsoft v ní integruje velice hluboce .NET CLR do samotného serveru. Nyní můžete ve svém oblíbeném jazyku programovat uživatelské funkce, uživatelské typy, úložné procedury, triggery nebo agregační funkce. Pro programovaní „uvnitř“ SQL serveru je vytvořen nový provider, sídlící ve jmenném prostoru System.Data.SqlServer – nová implementace komunikuje přímo se serverem a odpadá tak zbytečné zpomalení způsobené komunikací přes síťové vrstvy. Assembly, obsahující kód pro SQL server, se registrují také přímo do serveru, čímž odpadají problémy se zálohováním databáze. Plyne z toho ovšem jeden nepraktický důsledek, po každém přeložení assembly musí být tato umístěna na server. Naštěstí tento úkol provádí Visual Studio .NET automaticky při sestavování projektu. Integrace s Visual Studiem také umožňuje využívat verzovací software (například Visual SourceSafe), což ocení hlavně vývojáři větších projektů. Ti z vás, kteří vyvíjeli aplikace obsahující několik desítek až stovek úložných procedur, ví moc dobře, jaký to může být problém.

Novy Yukon obsahuje nástroj SQL Server Workbench, který je nápadně podobný Visual Studiu. Kombinuje schopnosti Query Analyzeru a Enterprise Manageru a umožňuje také ladění veškerého kódu (T-SQL i .NET) běžícího na serveru.

SQL Server Workbench, 30. 10. 2003 (plná velikost, cca 40 kB)

Zajímavá je otázka architektury řešení, postavených na Yukonu. Tím, že umožňuje běh .NET kódu uvnitř SQL serveru, může svádět vývojáře k přesouvání aplikační logiky do databáze. To může být určitě velice výkonné řešeni, u větších aplikací ovšem narazíme na problém škálovatelnosti.

Jako třešničku na konec jsem si nechal ObjectSpaces – jedná se o podpůrné knihovny, umožňující mapování mezi objektovou strukturou a relační databází. Přestože konkurenční Java standardy pro tento úkol poskytuje, .NET zatím takové řešení postrádal a velice tím zpomaloval vývoj velkých enterprise aplikací se silnou business vrstvou. ObjectSpaces podporuje mapování dědičnosti, vztahu „jedna k n“, nebo „n ku n“. Podpora databázových transakci, distribuovaných transakcí nebo optimistického zamykání je skloubena s relativně vysokým výkonem, ztráta oproti klasickému ADO.NET nemá být větší než 30 %. Osobně bych předpovídal ObjectSpaces velice světlou budoucnost, protože kompletně izoluje databázovou vrstvu od aplikace, čímž umožňuje databázovou nezávislost a teoreticky i budoucí přechod na objektovou databázi.

Shrnuto a podtrženo, Proffesional Developers Conference v Los Angeles ukázala, o kolik více má teď vývojář prostoru pro svou práci. GUI projekty se rozrostou o verze pro Avalon, poskytující širší grafické možnosti, databázová vrstva se bude moci programovat jak v SQL tak i v .NETu, data se budou moci od serveru na klienta přenášet pomocí DataSetu, XML nebo tlustých business objektů – vše s design-time podporou ve Visual Studiu. A vstupní zařízení se rozrostou o pero a mluvenou řeč…

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.