ASp.NET 2.0 a C#

E N C Y K L O P E D I E

Z O N E R

P R E S S

ASP.NET 2.O a C# tvorba dynamických stránek

PROFESIONÁLNĚ

© Foto: Jiří Heller

Matthew MacDonald Mario Szpuszta

ASP.NET 2.0 a C# tvorba dynamických stránek PROFESIONÁLNĚ Matthew MacDonald a Mario Szpuszta

Na knize dále spolupracovali K. Scott Allen, James Avery, Russ Basiura, Mike Batongbacal, Marco Bellinaso, Matt Butler, Andreas Eide, Daniel Cazzulino, Michael Clark, Richard Conway, Robert Eisenberg, Brady Gaster, James Greenwood, Kevin Hoffman, Erik Johansson, Angelo Kastroulis, Dan Kent, Sitaraman Lakshminarayanan, Don Lee, Christopher Miller, Matt Milner, Jan Narkiewicz, Matt Odhner, Ryan O‘Keefe, Andrew Reid, Matthew Reynolds, Enrico Sabbadin, Bill Sempf, Doug Seven, Srinivasa Sivakumar, Thiru Thangarathinam, Doug Thews.

Pro ASP.NET 2.0 in C# Matthew MacDonald, Mario Szpuszta.

Original English language edition published Apress L.P., 2560 Ninth Street, Suite 219, Berkeley, CA 94710 USA. Copyright © 2005 by Apress L.P. Czech language edition copyright © 2006 by ZONER software, s.r.o. All rights reserved.

No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Apress L.P. Originální anglické vydání vydal Apress L.P., 2560 Ninth Street, Suite 219, Berkeley, CA 94710 USA. Copyright © 2005 Apress L.P. České vydání vydal ZONER software, s.r.o., copyright © 2006. Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována nebo předávána žádnou formou nebo způsobem, elektronicky ani mechanicky, včetně fotokopií, natáčení ani žádnými jinými systémy pro ukládání bez výslovného svolení Apress L.P.

ASP.NET 2.0 a C# – tvorba dynamických stránek PROFESIONÁLNĚ Autor: Matthew MacDonald, Mario Szpuszta Copyright © ZONER software, s.r.o. Vydání první v roce 2006. Všechna práva vyhrazena.

Zoner Press Katalogové číslo: ZR515 ZONER software, s.r.o.

Nové sady 18, 602 00 Brno Překlad: RNDr. Jan Pokorný, Ing. Petr Kadlec, Erika Lencová Odpovědný redaktor: Miroslav Kučera Šéfredaktor: Ing. Pavel Kristián DTP: Miroslav Kučera © Cover foto: Jiří Heller, HELLER.CZ s.r.o, www.heller.cz © Cover: PYRAMIDE, s.r.o.

Informace, které jsou v této knize zveřejněny, mohou byt chráněny jako patent. Jména produktů byla uvedena bez záruky jejich volného použití. Při tvorbě textů a vyobrazení bylo sice postupováno s maximální péčí, ale přesto nelze zcela vyloučit možnost výskytu chyb. Vydavatelé a autoři nepřebírají právní odpovědnost ani žádnou jinou záruku za použití chybných údajů a z toho vyplývajících důsledků. Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována ani distribuována žádným způsobem ani prostředkem, ani reprodukována v databázi či na jiném záznamovém prostředku či v jiném systému bez výslovného svolení vydavatele, s výjimkou zveřejnění krátkých částí textu pro potřeby recenzí.

Veškeré dotazy týkající se distribuce směřujte na: Zoner Press ZONER software, s.r.o.

Nové sady 18, 602 00 Brno tel.: 532 190 883, fax: 543 257 245 e-mail: knihy@zoner.cz http://www.zonerpress.cz

ISBN 80-86815-38-2

3

Obsah Informace o autorech knihy

24

Informace o odborných korektorech

24

Úvod

25

Cesta ASP.NET od 1.0 k 2.0

25

Co naleznete v této knize?

26

Komu je kniha určena?

27

Co potřebujete, abyste mohli s knihou pracovat?

27

Sdělte nám svůj názor

28

Zdrojové soubory

28

Část I – Základy ASP.NET Kapitola 1

Úvod do ASP.NET

Evoluce webového vývoje Vývojový svět před příchodem ASP.NET

31 31 32

Co je špatného na klasickém ASP?

32

ASP.NET 1.0

35

Sedm důležitých faktů o ASP.NET

35

Fakt 1: ASP.NET je integrováno s .NET Frameworkem

35

Fakt 2: ASP.NET se neinterpretuje, ale kompiluje

36

Fakt 3: ASP.NET je vícejazyčné

38

Fakt 4: ASP.NET běží uvnitř společného runtime jazyků

40

Fakt 5: ASP.NET je objektově orientované

41

Fakt 6: ASP.NET podporuje různá zařízení a různé prohlížeče

43

Fakt 7: ASP.NET se snadno rozmisťuje a konfiguruje

44

ASP.NET 2.0 – příběh pokračuje

45

C# verze 2005

46

Visual Studio 2005

46

ASP.NET 2.0

47

Shrnutí

Kapitola 2

52

Visual Studio 2005

Vývojový model .NET

53 55

Kompilátor

55

Integrované vývojové rozhraní Visual Studia

55

Weby ve Visual Studiu Vývoj bez projektu

56 59

4 Migrace projektu Visual Studia .NET Navrhování webové stránky Integrované vývojové rozhraní Visual Studia

59 61 64

Průzkumník řešení

66

Okno dokumentu

68

Toolbox

68

Seznam chyb a seznam úkolů

69

Průzkumník serveru

71

Editor kódu

71

Přidání referencí na assembly

73

IntelliSense a osnova

75

Model vytváření kódu

79

Jak se soubory kódu v pozadí připojují k stránkám

81

Jak se připojují značky ovládacích prvků k proměnným stránky

82

Jak se připojují události ke ovladačům událostí

83

Ladění ve Visual Studiu

84

Ladění po krocích

85

Pokročilé body přerušení

88

Sledování proměnných

89

Makra Visual Studia

90

ASP.NET Development Helper

92

Shrnutí

94

Kapitola 3

Webové formuláře

Zpracování stránky

95 96

HTML formuláře

97

Dynamická rozhraní

99

Model událostí ASP.NET

100

Automatické odesílání zpět na server

101

Stav zobrazení

102

Soulad s XHTML

107

Etapy zpracování webového formuláře

110

Inicializace pracovního rámce stránky

111

Inicializace uživatelského kódu

112

Validace

112

Zpracování událostí

113

Automatické vázání dat

113

Údržba

114

Ukázka toku zpracování stránky

114

Stránka jako kontejner ovládacích prvků

117

5 Zobrazení stromu ovládacích prvků

117

Záhlaví stránky

121

Dynamické vytváření ovládacích prvků

122

Třída Page

124

Objekty Session, Application a Cache

125

Objekt Request

125

Objekt Response

126

Objekt Server

128

Objekt User

130

Objekt Trace

131

Přístup ke kontextu HTTP v jiné třídě

137

Shrnutí

Kapitola 4

138

Serverové ovládací prvky

Typy serverových ovládacích prvků Hierarchie serverového ovládacího prvku Serverové ovládací prvky HTML

139 140 142 143

Třída HtmlControl

144

Třída HtmlContainerControl

145

Třída HtmlInputControl

145

Třídy serverových ovládacích prvků HTML

146

Nastavování atributů stylu a jiných vlastností

147

Programátorské vytváření serverových ovládacích prvků

149

Zpracování událostí na straně serveru

150

Webové ovládací prvky

153

Základní třída WebControl

154

Základní třídy webových ovládacích prvků

155

Jednotky

157

Výčtové hodnoty

158

Barvy

158

Písma

159

Focus

160

Výchozí tlačítko

162

Panely s rolováním

162

Zpracování událostí webových ovládacích prvků

163

Ovládací prvky pro seznamy

166

Ovládací prvky seznamů, z nichž lze vybírat

167

Ovládací prvek BulletedList

170

Ovládací prvky pro ověřování platnosti vstupu Validační ovládací prvky

172 172

6 Proces ověřování platnosti

173

Třída BaseValidator

175

Ovládací prvek RequiredFieldValidator

176

Ovládací prvek RangeValidator

177

Ovládací prvek CompareValidator

177

Ovládací prvek RegularExpressionValidator

178

Ovládací prvek CustomValidator

181

Ovládací prvek ValidationSummary

182

Programátorské využívání validátorů

183

Validační skupiny

185

Bohatě vybavené ovládací prvky ASP.NET

187

Ovládací prvek AdRotator

188

Ovládací prvek Calendar

189

Shrnutí

Kapitola 5

192

Aplikace ASP.NET

193

Anatomie aplikace ASP.NET

194

Doména aplikace

194

Doba života aplikace

195

Aktualizace aplikací

196

Struktura adresáře aplikace

196

Soubor aplikace global.asax

197

Události aplikace

199

Ukázka zpracování událostí aplikace

201

Konfigurace ASP.NET

202

Soubor machine.config

202

Soubor web.config

205

Konfigurační nastavení

207

Programátorské čtení a zápis konfiguračních nastavení

212

Nástroj WAT (Website Administration Tool)

215

Rozšiřování struktury konfiguračního souboru

217

Šifrování konfiguračních sekcí

219

Komponenty .NET

221

Vytvoření komponenty

222

Použití komponenty prostřednictvím adresáře App_Code

223

Použití komponenty prostřednictvím adresáře Bin

224

Rozšiřování kanálu HTTP

227

Ovladače HTTP a moduly HTTP

227

Vytvoření vlastního ovladače HTTP

229

Konfigurace vlastního ovladače HTTP

230

7 Registrace ovladačů HTTP bez konfigurování IIS

231

Vytvoření pokročilejšího ovladače HTTP

232

Vytvoření vlastního modulu HTTP

235

Shrnutí

Kapitola 6

238

Správa stavu

239

Správa stavu ASP.NET

240

Stav zobrazení

243

Ukázka práce se stavem zobrazení

243

Ukládání objektů do stavu zobrazení

245

Zachování členských proměnných

248

Přístup ke stavu zobrazení

248

Ořezání stavu zobrazení pro ovládací prvky seznamů

250

Bezpečnost stavu zobrazení

251

Přenášení informací Dotazovací řetězec

252 253

Odesílání stránky zpět na server přes jinou stránku

254

Odesílání zpět na server přes jinou stránku a ověřování platnosti

258

Vlastní cookies

259

Stav relace

261

Architektura relace

261

Použití stavu relace

263

Konfigurace stavu relace

264

Zabezpečení stavu relace

269

Stav aplikace

270

Statické proměnné aplikace Shrnutí

272 274

Část II – Přístup k datům Kapitola 7

Základy ADO.NET

Architektura ADO.NET

277 278

Poskytovatelé dat ADO.NET

279

Standardizace v ADO.NET

280

SQL Server 2005

281

Základní třídy ADO.NET

282

Třídy připojení

283

Připojovací řetězce

283

Testování připojení

285

8 Fond připojení

286

Statistiky připojení

288

Třídy příkazů a čtenářů dat

289

Základní informace o třídách příkazů

289

Třídy čtenářů dat

290

Metoda ExecuteReader() a čtenář dat

291

Metoda ExecuteScalar()

296

Metoda ExecuteNonQuery()

296

Útoky injektáží SQL

297

Práce s parametrizovanými příkazy

300

Volání uložených procedur

301

Transakce 303 Transakce a aplikace ASP.NET

304

Úrovně izolace

308

Záchytné body

309

Vnořované transakce

310

Kód nedogmatický vzhledem k poskytovatelům Vytvoření továrny na objekty

310 311

Vytváření objektů v továrně

312

Dotaz s nedogmatickým kódem vzhledem k poskytovatelům

313

Shrnutí

Kapitola 8

314

Datové komponenty a sada dat

Budování komponenty pro přístup k datům Balík dat

315 315 317

Uložené procedury

318

Třída databázových utilit

319

Testování komponenty

325

Odpojená data

327

Webové aplikace a sada dat

328

Integrace XML

329

Třídy sady dat

329

Třída DataTable

331

Třída DataRow

331

Třídy datového adaptéru

331

Plnění sady dat

333

Práce s více tabulkami najednou a vztahy

334

Vyhledávání konkrétních řádků

337

Použití sady dat ve vlastní třídě dat

338

Vázání dat

339

9 Třída DataView

339

Řazení pomocí DataView

340

Filtrování dat pomocí DataView

341

Vyspělé filtry založené na relacích

343

Vypočítané sloupce

344

Shrnutí

Kapitola 9

346

Vázání dat

Základy vázání dat

347 348

Jednoduché vázání dat

348

Další typy výrazů

350

Složené vázání dat Ovládací prvky pro zdroje dat Životní cyklus stránky s vázáním dat Ovládací prvek SqlDataSource

354 362 363 364

Výběr záznamů

365

Parametrizované příkazy

368

Zpracování chyb

372

Aktualizace záznamů

372

Nevýhody ovládacího prvku SqlDataSource

377

Ovládací prvek ObjectDataSource

378

Výběr záznamů

378

Aktualizace záznamů

383

Aktualizace pomocí datového objektu

384

Limity ovládacích prvků pro zdroje dat

387

Specifikace problému

387

Přidání dalších prvků

388

Zpracování dodatečných voleb s SqlDataSource

389

Zpracování dodatečných voleb s ObjectDataSource

390

Shrnutí

Kapitola 10

390

Bohatě vybavené ovládací prvky

Ovládací prvek GridView Definice sloupců Formátování GridView Formátování polí vázaných na data

391 392 392 396 396

Styly

398

Formátování pouze některých hodnot

402

Výběr řádků v GridView Využití výběru pro formulář typu hlavní řádek – asociované řádky

404 405

10 Událost SelectedIndexChanged

406

Použití datového sloupce jako tlačítka pro výběr

407

Řazení v GridView

408

Řazení s SqlDataSource

408

Řazení s ObjectDataSource

409

Řazení a výběr

411

Složitější řazení

412

Stránkování GridView

414

Automatické stránkování

414

Vlastní stránkování s ObjectDataSource

415

Přizpůsobení pruhu s ovládacími prvky pro stránkování

419

Šablony GridView

420

Použití vícenásobných šablon

421

Editace šablon ve Visual Studiu

423

Vázání k metodě

423

Zpracování událostí v šabloně

425

Editace se šablonou

426

DetailsView a FormView

432

Ovládací prvek DetailsView

432

Ovládací prvek FormView

434

Pokročilé mřížky

436

Souhrny v GridView

436

Zobrazení rodič/potomek v jediné tabulce

437

Obsluha obrázků z databáze

440

Detekce konfliktů při simultánním zpracování Shrnutí

Kapitola 11

446 450

Ukládání do cache

451

Chápeme cachování v ASP.NET

452

Cachování výstupu

453

Deklarativní cachování výstupu

453

Cachování a dotazovací řetězec

454

Cachování s konkrétními parametry dotazovacího řetězce

455

Vlastní řízení cachování

456

Cachování s třídou HttpCachePolicy

458

Nahrazení po uložení do cache a cachování fragmentů

459

Profily cache

461

Cachování na disk Cachování dat Přidávání položek do kolekce Cache

462 463 464

11 Jednoduchý test cache

466

Priority cache

467

Cachování s ovládacími prvky pro zdroje dat

468

Závislosti cache

471

Závislosti na souboru a položce cache

472

Souhrnné závislosti

473

Zpětné volání při odstranění položky

474

Notifikace SQL do cache

476

Notifikace cache v SQL Serveru 2000 nebo SQL Serveru 7

477

Notifikace cache v SQL Serveru 2005

482

Vlastní závislosti cache

483

Základní vlastní závislost cache

484

Vlastní závislost cache používající fronty zpráv

485

Shrnutí

Kapitola 12

487

XML

489

Kdy je rozumné používat XML?

490

Úvod do XML

490

Výhody XML

491

Správně strukturovaný XML

492

Jmenné prostory XML

493

Schémata XML

494

Zápis a čtení XML programátorsky

496

Zápis souborů XML

496

Čtení souborů XML

500

Ověřování platnosti souborů XML Zobrazování obsahu XML s XSL

513 516

Základní stylový předpis

516

Práce s třídou XslTransform

517

Práce s ovládacím prvkem Xml

518

Vázání dat XML

519

Vázání, které není hierarchické

519

Použití XPath

521

Vnořené mřížky

524

Hierarchické vázání s TreeView

525

Práce s XSLT

527

Vázání k obsahu XML z jiných zdrojů

529

Aktualizace XML prostřednictvím XmlDataSource

530

XML a ADO.NET Konverze sady dat do XML

530 531

12 Přístup k sadě dat prostřednictvím XML Vykonání dotazu XML Shrnutí

Kapitola 13

533 534 536

Soubory a proudy

Práce se systémem souborů

537 538

Třídy Directory a File

538

Třídy DirectoryInfo a FileInfo

541

Třída DriveInfo

544

Práce s atributy souboru nebo adresáře

545

Filtrování souborů pomocí zástupných symbolů

546

Získávání informací o verzi souboru

547

Třída Path

548

Prohlížeč souborů

551

Čtení a zapisování souborů pomocí proudů

555

Textové soubory

557

Binární soubory

558

Nahrávání souborů na server

559

Tvorba souborů bezpečných pro více uživatelů

561

Komprimace

566

Serializace

567

Shrnutí

570

Část III – Budování webů ASP.NET Kapitola 14

Uživatelské ovládací prvky

Základy uživatelského ovládacího prvku

573 574

Vytvoření jednoduchého uživatelského ovládacího prvku

574

Konverze stránky na uživatelský ovládací prvek

576

Přidávání kódu do uživatelského ovládacího prvku

577

Zpracování událostí

577

Přidávání vlastností

579

Práce s vlastními objekty

581

Přidávání událostí

583

Vystavování vnitřku webového ovládacího prvku

587

Dynamické nahráváníuživatelských ovládacích prvků

588

Pracovní rámce portálů

588

Částečné cachování stránky

591

13 Vlastnost VaryByControl

592

Sdílení ovládacích prvků uložených do cache

594

Shrnutí

Kapitola 15

594

Motivy a vzory stránek

Standardizace formátování webu Kaskádové styly (CSS) Motivy

595 595 595 598

Složky motivu a skinové předpisy

599

Jak se aplikuje jednoduchý motiv

600

Zpracování konfliktů souvisejících s motivem

602

Vytvoření více skinových předpisů pro jeden ovládací prvek

603

Skinové předpisy se šablonami a obrázky

604

Použití CSS v motivu

606

Aplikování motivů prostřednictvím konfiguračního souboru

607

Dynamické aplikování motivu

608

Standardizace layoutu webu

610

Co je vzor stránek

610

Jednoduchý vzor stránek

611

Jednoduchá stránka s obsahem

613

"Manýry" vzoru stránek v době návrhu

615

Výchozí obsah

618

Praktičtější ukázka vzoru stránek

618

Vzory stránek a relativní cesty

620

Vzory stránek a formátování

621

Použití vzorů stránek prostřednictvím konfiguračního souboru

621

Pokročilé vzory stránek

622

Specifikace titulku a metaznaček pro stránku s obsahem

622

Interakce s třídou vzoru stránek

623

Dynamické nastavení vzoru stránek

624

Vnořování vzorů stránek

625

Shrnutí

Kapitola 16

626

Navigace po webu

Stránky s více zobrazeními

627 627

Ovládací prvek MultiView

628

Ovládací prvek Wizard

632

Mapa webu

640

Definice mapy webu

641

Vázání k mapě webu

643

14 Navigační cesta

644

Vázání částí mapy webu

646

Navigace řešená programátorsky

649

Vázání jiných ovládacích prvků

651

Přidávání vlastních informací do plánu webu

652

Vytvoření vlastního poskytovatele plánu webu

653

Mapování URL

658

Ovládací prvek TreeView

659

Objekty TreeNode

660

Plnění uzlů na požádání

663

Styly TreeView

664

Ovládací prvek Menu

668

Styly ovládacího prvku Menu

671

Šablony ovládacího prvku Menu

673

Shrnutí

Kapitola 17

674

Zdroje a lokalizace

675

Zdroje v aplikacích .NET

675

Lokalizace webových aplikací

683

Lokalizace a společný runtime jazyků (CLR)

684

Lokální zdroje pro jedinou stránku

687

Sdílení zdrojů mezi stránkami

692

Lokalizace statického textu

694

Směr textu

694

Shrnutí

Kapitola 18

695

Rozmístění webu

Internet Information Services (IIS)

697 697

IIS a zpracování URL

698

Zpracování požadavku s IIS a ASP.NET

701

Model IIS 5.x

702

Model IIS 6.0

705

Instalace IIS

710

Správa a řízení webů

712

Vytvoření virtuálního adresáře

713

Virtuální adresáře a webové aplikace

715

Nastavení složky Správa aplikačních fondů v IIS 6.0

715 720

Vytváření aplikačních fondů

720

Aplikační fondy a webové aplikace

723

15 Vlastní identity aplikačního fondu

724

Jak rozmístit vaše aplikace ASP.NET

727

Ověření instalace ASP.NET

728

Vykonávání ASP.NET bok po boku

730

Konfigurace nastavení HTTP Runtime

731

Modely kompilace

732

Rozmisťování pomocí Visual Studia

734

Třída VirtualPathProvider v ASP.NET 2.0

736

Monitorování zdravotního stavu v ASP.NET 2.0

741

Základní struktura

741

Události a poskytovatelé

741

Shrnutí

745

Část IV – Bezpečnost Kapitola 19

Bezpečnostní model ASP.NET

Co znamená tvorba bezpečného software

749 749

Chápeme potenciální hrozby

750

Zásady bezpečného programování

750

Pochopení strážných

751

Chápeme úrovně bezpečnosti

752

Autentizace

753

Autorizace

754

Důvěrnost a integrita

755

Jak všechno spojit dohromady

755

Bezpečnost IIS

757

Autentizace IIS

757

Autorizace IIS

759

IIS a SSL

760

Bezpečnostní architektura ASP.NET Autentizace

765 767

Autorizace

768

Bezpečnostní kontext

769

API pro členství a role

770

Shrnutí

Kapitola 20

771

Formulářová autentizace

Představení formulářové autentizace Proč používat formulářovou autentizaci?

773 773 774

16 Proč nepoužívat formulářovou autentizaci?

776

Proč neimplementovat vlastní autentizaci pomocí cookie?

777

Třídy formulářové autentizace

778

Implementace formulářové autentizace

779

Konfigurace formulářové autentizace

779

Odmítnutí přístupu anonymním uživatelům

782

Tvorba vlastní přihlašovací stránky

783

Vlastní úložiště přihlašovacích dokladů

789

Trvalé cookies ve formulářové autentizaci

790

Shrnutí

Kapitola 21

791

Členství

793

Úvod do API pro členství ASP.NET

793

Práce s API pro členství

796

Konfigurace formulářové autentizace

797

Vytvoření úložiště dat

798

Konfigurace připojovacího řetězce a poskytovatele členství

802

Vytváření a autentizace uživatelů

806

Práce s ovládacími prvky pro bezpečnost

808

Ovládací prvek Login

809

Ovládací prvek LoginStatus

819

Ovládací prvek LoginView

819

Ovládací prvek PasswordRecovery

820

Ovládací prvek ChangePassword

825

Ovládací prvek CreateUserWizard

826

Použití třídy Membership

831

Získávání uživatelů z úložiště

832

Aktualizace uživatelů v úložišti

834

Vytváření a odstraňování uživatelů

835

Ověřování uživatelů

836

Shrnutí

Kapitola 22

836

Autentizace Windows

Představení autentizace Windows Proč používat autentizaci Windows?

837 837 837

Proč nepoužívat autentizaci Windows?

839

Mechanismy autentizace Windows

839

Implementace autentizace Windows

846

Konfigurace IIS

846

Konfigurace ASP.NET

848

17 Odepření přístupu anonymním uživatelům

848

Přístup k informacím uživatele Windows

848

Impersonalizace

852

Impersonalizace ve Windows 2000

853

Impersonalizace ve Windows XP

854

Impersonalizace a delegování v systému Windows Server 2003

854

Konfigurovatelná impersonalizace

857

Programová impersonalizace

859

Shrnutí

Kapitola 23

862

Autorizace a role

Autorizace URL

863 863

Autorizační pravidla Souborová autorizace Autorizační kontroly v kódu

864 870 871

Použití metody IsInRole()

871

Použití třídy PrincipalPermission

871

Použití služby rolía autorizace založené na rolích

874

Použití ovládacího prvku LoginView s rolemi

880

Programátorský přístup k rolím

881

Použití služby rolí v autentizaci Windows

884

Ochrana jiných zdrojů, než jsou webové stránky

886

Mapování dalších typů souborů

887

Vytvoření vlastního ovladače HTTP

888

Shrnutí

Kapitola 24

890

Profily

Chápeme profily

891 891

Představení profilů

892

Jak profily ukládají data

893

Profily a autentizace

893

Profily a datové komponenty Používání SqlProfileProvider

894 895

Vytvoření tabulek profilu

895

Konfigurace poskytovatele

897

Definování vlastností profilu

898

Použití vlastností profilu

899

Serializace profilu

901

Skupiny profilu

903

Profily a vlastní datové typy

904

18 API pro profily

907

Anonymní profily

909

Tvorba nákupního košíku

912

Třídy nákupního košíku

913

Testovací stránka

915

Několikanásobný výběr

918

Vlastní poskytovatelé profilu

919

Třídy vlastních poskytovatelů profilu

919

Návrh FactoredProfileProvider

921

Naprogramování FactoredProfileProvider

922

Testování FactoredProfileProvider

927

Shrnutí

Kapitola 25

929

Šifrování

931

Šifrování dat – diskrétnost

931

Šifrovací jmenný prostor .NET

932

Úvod do šifrovacích tříd .NET

935

Symetrické šifrovací algoritmy

936

Asymetrické šifrování

937

Abstraktní šifrovací třídy

938

Rozhraní ICryptoTransform

939

Třída CryptoStream

939

Šifrování citlivých dat

940

Správa tajných údajů

940

Používání symetrických algoritmů

942

Používání asymetrických algoritmů

947

Šifrování citlivých dat v databázi

949

Šifrování dotazovacího řetězce

953

Obalení dotazovacího řetězce

953

Vytvoření testovací stránky

956

Shrnutí

Kapitola 26

958

Vlastní poskytovatelé členství

959

Architektura vlastních poskytovatelů

959

Základní kroky nutné provytvoření vlastních poskytovatelů

961

Celkový návrh vlastního poskytovatele

961

Návrh a implementace vlastního úložiště

962

Implementace tříd poskytovatelů

969

Používání tříd vlastních poskytovatelů

989

Shrnutí

991

19

Část V – Pokročilé uživatelské rozhraní Kapitola 27

Vlastní serverové ovládací prvky

Základy vlastních serverových ovládacích prvků

995 996

Vytvoření kostry vlastních ovládacích prvků

997

Použití vlastního ovládacího prvku

999

Vlastní ovládací prvky v Toolboxu

1000

Tvorba webového ovládacího prvku s podporou vlastností stylu

1002

Proces realizace

1005

Práce s různými prohlížeči

1007

HtmlTextWriter

1007

Detekce prohlížeče

1008

Vlastnosti prohlížeče

1010

Přizpůsobivá realizace prvků Stav ovládacích prvků a události

1012 1014

Stav zobrazení

1014

Správa stavu

1016

Data postbacku a události změn

1018

Spouštění postbacku

1020

Rozšíření existujících webových ovládacích prvků

1022

Složené ovládací prvky

1023

Odvozené ovládací prvky

1025

Ovládací prvky šablon Vytvoření ovládacího prvku šablony

1030 1031

Používání upravených šablon

1033

Styly

1037

Shrnutí

Kapitola 28

1040

Podpora v době návrhu

Atributy v době návrhu

1041 1042

Okno Properties

1043

Atributy a dědičnost

1046

Ikona Toolbox

1047

Webové zdroje

1048

Serializace kódu

1050

Typové konvertory

1051

Atributy serializace

1059

Typové editory Designéři ovládacích prvků

1066 1068

20 Základní designér ovládacího prvku Inteligentní značky (Smart Tags)

1069 1072

Seznam akcí

1072

Kolekce DesignerActionItem

1074

Designér ovládacího prvku (Control Designer)

1076

Shrnutí

Kapitola 29

1077

JavaScript

Základy JavaScriptu

1079 1079

Události JavaScriptu

1080

Bloky skriptu

1082

Realizování bloků skriptu

1091

Útoky injektáží skriptu

1092

Funkce pro ověření požadavku

1093

Vypnutí funkce pro ověření požadavku

1094

Zpětné volání klienta

1096

Vytvoření zpětného volání klienta

1096

Pozadí zpětného volání klienta

1101

Vlastní ovládací prvky s JavaScriptem Pop-up okna

1103 1103

Rollover tlačítka

1106

Dynamické panely

1109

Rámce

1113

Navigace v rámcích

1114

Řádkové rámce

1116

Souhrn

Kapitola 30

1117

Dynamická grafika a GDI+

Ovládací prvek ImageMap

1119 1119

Vytváření aktivních oblastí

1120

Ošetření kliknutí do aktivních oblastí

1122

Vlastní aktivní oblasti Kreslení s GDI+

1123 1125

Jednoduché kreslení

1126

Formát a kvalita obrázku

1128

Třída Graphics

1129

Použití GraphicsPath

1131

Pera

1133

Štětce Vložení dynamické grafiky do webové stránky

1135 1137

21 Použití formátu PNG

1138

Předávání informací dynamickým obrázkům

1139

Vlastní ovládací prvky používající GDI+

1142

Vytváření grafů za pomoci GDI+

1147

Shrnutí

1152

Kapitola 31

Portály s webovými částmi

1153

Typické stránky portálu

1153

Základní stránka s webovými částmi

1155

Vytvoření návrhu stránky

1156

WebPartManager a WebPartZones

1157

Přidání webové části na stránku

1159

Přizpůsobení stránky

1162

Vytvoření webových částí

1165

Jednoduché úkoly webových částí

1165

Vývoj pokročilých webových části

1174

Editory webových částí

1183

Připojení webových částí

1189

Webové části a autorizace

1197

Poslední kroky personalizace Shrnutí

1198 1199

Část VI – Webové služby Kapitola 32

Tvorba webových služeb

Přehled webových služeb Historie webových služeb

1203 1204 1205

Distribuované výpočty a webové služby

1206

Problémy spojené s technologiemi distribuovaných komponent

1207

Výhody webových služeb

1208

Vydělávání peněz s webovými službami

1209

Standardy používané webovými službami

1210

Budování základní webové služby Třída webové služby

1213 1213

Požadavky na webovou službu

1214

Vystavení webové služby

1217

Testování webové služby

1221

Používání webové služby Třída proxy

1224 1230

22 Vytvoření klienta ASP.NET

1231

Vytvoření klienta formulářů Windows

1234

Vytvoření ASP klienta s MSXML

1236

Vytvoření ASP klienta pomocí SOAP Toolkit

1237

Vylepšování webové služby

1238

CacheDuration

1239

EnableSession

1242

BufferResponse

1245

TransactionOption

1245

Shrnutí

Kapitola 33

1248

Standardy webové služby a rozšíření

1249

Součinnost WS

1249

SOAP

1251

Kódování SOAP

1252

Verze SOAP

1253

Trasování SOAP zpráv

1254

SOAP obálka

1256

Záhlaví SOAP

1261

WSDL

1265

Zobrazování WSDL pro webovou službu

1265

Základní struktura

1267

Implementace existujícího kontraktu Přizpůsobování zpráv SOAP

1272 1274

Serializace komplexních datových typů

1274

Přizpůsobení XML serializace s atributy

1279

Sdílení typů

1282

Přizpůsobení XML serializace pomocí IXmlSerializable

1284

Vlastní serializace rozsáhlých datových typů

1288

Rozšíření importéru schématu Shrnutí

Kapitola 34

1294 1297

Pokročilé webové služby

Asynchronní volání

1299 1300

Asynchronní delegáti

1300

Jednoduché asynchronní volání

1302

Souběžné asynchronní volání

1304

Interaktivní klienti Windows

1306

Asynchronní služby

1310

Zabezpečení webových služeb

1311

23 Autentizace Windows

1311

Vlastní autentizace založená na lístcích

1314

Sledování identity uživatele

1314

Autentizace uživatele

1316

Autorizace uživatele

1317

Testování systému autentizace SOAP Rozšíření SOAP Vytvoření rozšíření SOAP Vylepšení webových služeb

1317 1319 1321 1329

Instalace WSE

1330

Provádění autentizace s WSE

1331

Shrnutí

1336

Rejstřík

1337

24

Informace o autorech knihy MATTHEW MACDONALD je autor, pedagog a vývojář MCSD. Pravidelně přispívá do časopisů o programování a je autorem více než tuctu knih o programování .NET, např.

ASP.NET: The Complete Reference (Osborne McGraw-Hill, 2002), Programming .NET Web Services (O’Reilly, 2002), Beginning ASP.NET in C (Apress, 2004) a Microsoft .NET Distributed Applications (Microsoft Press, 2003). V šerém dávnověku svého života studoval anglickou literaturu a teoretickou fyziku.

MARIO SZPUSZTA pracuje v Developer and Platform Group u společnosti Microsoft v Rakousku. Než začal pracovat pro Microsoft, participoval Mario na několika projektech založených na COM+ a DCOM s jazyky Visual Basic a Visual C++, a také na projektech založených na Java a J2SE. Počínaje první verzí beta 2 .NET Frameworku začal vyvíjet webové aplikace s ASP.NET. V současné době, jakožto horlivý vývojářský misionář Microsoft Austria, řídí workshopy, školení a demonstrační projekty s nezávislými výrobci softwaru v Rakousku, a to na základě technologií webových služeb .NET a Office 2003.

Informace o odborných korektorech ROBERT LAIR je prezident a ředitel Intensity Software (http://www.intensitysoftware.com), která se specializuje na poradenské služby Microsoft .NET. Intensity nabízí kromě poradenských služeb také Kicks for .NET, což je migrační utilita z CICS-do-ASP.NET, která automatizuje migrační proces, přičemž současně udržuje zdrojový kód stávající obchodní logiky. Robert se podílel na vytvoření demonstrační aplikace IBuySpy Store a Portal, a také NetCOBOL for .NET verzi IBuySpy a ukázky QuickStart. Robert jako autor participoval na řadě knih a napsal řadu článků na témata vztahující se k Microsoft .NET. Robertův osobní web je na adrese http://www.robertlair.com a jeho blog na http://www.robertlair.com/blogs/lair.

Robert by rád poděkoval své krásné ženě, Debi, a svému čtyřletému synovi, Maxovi, že se smířili se ztrátou rodinného života, který padl za oběť, když revidoval tuto knihu.

JASON LEFEBVRE je vicepresident a jeden ze zakládajících partnerů Intensity Software. Každodenně pracuje s Visual Studiem a s Microsoft .NET Frameworken, když připravuje architektury řešení pro klienty poradenských služeb Intensity. Podílel se na vytvoření demonstrační aplikaci IBuySpy Store, a také na překladu NetCOBOL for .NET. Jason participoval jako autor na mnoha knihách a napsal řadu článků na témata vztahující se k Microsoft .NET. Rád by poděkoval novému mazlíčkovi své přítelkyně, Oliverovi, že je tak rozkošný.

25

Úvod U vývojářů není nijak obtížné vzbudit zájem o ASP.NET. Aniž bychom přeháněli, dá se říci, že ASP.NET je nejkompletnější platformou pro webový vývoj, jaká byla kdy dána dohromady. Daleko předčí svého předchůdce, kterým bylo ASP, a které představovalo narychlo sestavenou sadu nástrojů pro vkládání dynamického obsahu do obyčejných webových stránek. ASP.NET je naproti tomu plnohodnotná platforma pro vývoj plnohodnotných a bleskově rychlých webových aplikací.

V této knize se dozvíte vše, co potřebujete znát, abyste mistrovsky ovládli ASP.NET 2.0. Jestliže jste už programovali s předchozí verzí ASP.NET, rychle prolétnete základy a hned se začnete dozvídat a nových vzrušujících schopnostech verze 2.0. Jestliže jste ještě nikdy neprogramovali s ASP.NET, zjistíte, že kniha vám poskytne správně dávkovanou okružní jízdu, která vás seznámí nejenom se všemi základními věcmi, ale zároveň vám umožní nahlédnout do zákulisí, takže zjistíte, jak ve skutečnosti fungují vnitřnosti ASP.NET. Kniha od vás požaduje jediné. Že dobře rozumíte jazyku C# a základům .NET. Jste-li příležitostným vývojářem v Javě nebo C++, ale s C# teprve začínáte, možná bude lepší, abyste si nejprve přečetli nějakou knihu věnovanou základům .NET – zkuste třeba knihu C# and the .NET 2.0 Platform, Third Edition (Apress, 2005), což je vyčerpávající úvod, nebo knihu A Programmer’s Introduction to C# 2.0, Third Edition (Apress, 2005).

Cesta ASP.NET od 1.0 k 2.0 Jak už nepochybně víte, ASP.NET je technologie nové generace od společnosti Microsoft pro vytváření webových aplikací na straně serveru. Je založená na Microsoft .NET Frameworku, což je rámec provázaných technologií, v nichž je téměř vše revoluční – od přístupu k databázím až k distribuovaným aplikacím. ASP. NET je jednou z nejdůležitějších komponent .NET Frameworku – je to část, která umožňuje vyvíjet vysoce výkonné webové aplikace a webové služby.

ASP.NET 1.0 způsobilo revoluci ve světě webového programování. Stalo se populárním tak prudce, že jeho licenci si obstaraly prostřednictvím licenčního programu Go-Live společnosti Microsoft tisíce komerčních webových serverů ještě v době, kdy byl ještě ve fázi beta. Finální verze ASP.NET 1.0 byla vydána na počátku roku 2002.

ASP.NET 1.1 nebylo až tak ambiciózní. Pro architekty společnosti Microsoft představovalo příležitost, aby se mohli na chvíli zastavit a nabrat kolektivní dech. ASP.NET 1.1 se nesoustředilo na nové schopnosti (žádné v něm nebyly), ale spíše na vyladění výkonu, na dopracování záležitostí týkajících se bezpečnosti, a na opravy drobnějších závad. Nové schopnosti byly tiše strčeny do šuplíků a uschovány pro další hlavní milník, kterým se mělo stát ASP.NET 2.0. ASP.NET 1.1 byl vydáno ke konci roku 2003, a učinilo z ASP.NET solidní platformu pro webový vývoj, jednu z voleb pro profesionální webové vývojáře.

Až za dva další dlouhé roky se konečně na obzoru objevilo ASP.NET 2.0. Na rozdíl od vydání ASP.NET 1.0, ASP.NET 2.0 nereprezentuje začátek nové éry webového vývoje. A skutečně – téměř veškerá podkladová architektura, o kterou se opíralo ASP.NET 1.0, zůstala v ASP.NET 2.0 stejná. Rozdíl spočívá v tom, že ASP. NET 2.0 přidává k existující technologii další vrstvy vysokoúrovňových schopností. Po úspěchu ASP.NET 1.0 společnost Microsoft nasměrovala všechny své vývojáře, čas a prostředky na plánování a přípravu ASP.NET 2.0. Když Microsoft zjistil, že není potřeba přepisovat engine ASP.NET, členové týmu ASP.NET dostali větší volnost, a mohli se věnovat inovacím v podobě nových ovládacích prvků, mohli vytvářet dokonalejší řešení správy dat, vybudovat bezpečnostní rámec založený na rolích, a dokonce mohli vyrobit celou soupravu nástrojů pro vytváření webových portálů. Stručně řečeno – ASP.NET 2.0 dává vývojářům šanci si v klidu nabírat z plné mísy nových dobrot, které byly navrženy pro jejich oblíbenou platformu. V této knize se dozvíte o tom, jak se všechny tyto schopnosti používají, přizpůsobují a rozšiřují.

26

Co naleznete v této knize?

Podívejte se na stručný přehled toho, co vás čeká v této knize:

•

Část I – Základy ASP.NET. Začíná se kapitolou 1, kde se z všeobecného hlediska podíváte na platformu ASP.NET, na .NET Framework, a na změny ve výbavě ASP.NET 2.0. V kapitole 2 rozšíříte své dovednosti tím, že se naučíte zacházet s Visual Studiem 2005. V kapitolách 3, 4, 5 a 6 se dozvíte o klíčových částech infrastruktury ASP.NET, kam patří model webové stránky, konfigurace aplikace, správa stavu a ukládání do cache. Až zvládnete tyto nepostradatelné pojmy, sestoupíte poněkud níž a podíváte se, jak ASP.NET zpracovává požadavky, a jak spravuje dobu života webových aplikací.

Také se dozvíte, jak se dá architektura ASP.NET rozšiřovat.

•

Část II – Přístup k datům. Tato část se zabývá jednou z klíčových oblastí každého vývoje softwaru – přístupem k datům a manipulací s nimi. V kapitolách 7 a 8 probereme, jak se aplikují základní prvky ADO.NET ve webových aplikacích, a dozvíte se, jak navrhovat komponenty pro přístup k datům. V kapitolách 9 a 10 se dozvíte o sadě nových datových ovládacích prvků ASP.NET, které umožňují formátovat a prezentovat data, aniž byste museli vytvářet dlouhé pasáže kódu. V kapitole 11 přejdeme k vyspělým strategiím cachování dat, jimiž si zajistíte bleskurychlý výkon. A konečně – v kapitolách 12 a 13 se přesuneme k databázím. Ukážeme vám, jak pracovat s obsahem v podobě XML, a jak zpracovávat běžný přístup k souborům.

•

Část III – Budování webů ASP.NET. V této části se dozvíte o podstatných technikách a schopnostech pro správu skupin webových stránek. V kapitole 14 začneme s jednoduchými uživatelskými ovládacími prvky, s jejichž pomocí budeme schopni využívat části uživatelského rozhraní. V kapitole 15 se podíváte na dvě nové inovace ASP.NET – motivy (pro automatizaci vzhledu ovládacích prvků) a vzory stránek (pro opětovné využití jedné šablony layoutu ve více stránkách).V kapitole 16 vám ukážeme, jak se v ASP.NET 2.0 používá nový navigační model ASP.NET 2.0, který slouží k tomu, abyste vašim návštěvníkům umožnili pohodlně přecházet z jedné stránky na jinou. V kapitole 17 společně prozkoumáme lokalizaci, v kapitole 18 si popíšeme rozmisťování aplikací, také webový server IIS.

•

Část IV – Bezpečnost. V této části se podíváte na bohatou výbavu schopností ASP.NET, které se týkají bezpečnosti. V kapitole 19 začnete vysokoúrovňovým přehledem bezpečnostních pojmů a dozvíte se o výhodách a nevýhodách formulářové autentizace (kapitola 20), a o novém API pro členství (kapitola 21), které s formulářovou autentizací spolupracuje. V kapitole 22 se budete potýkat s autentizací Windows. V kapitole 23 se dozvíte o tom, jak uplatnit na autentizované uživatele restrikce pomocí sofistikovaných autorizačních pravidel, a zjistíte, jak se pracuje s bezpečností založenou na rolích. V kapitole 24 prozkoumáte API pro profily, což je nové, předem vybudované, řešení pro ukládání informací specifických pro jednotlivé uživatele. V kapitole 25 pokročíte ještě dál. Dozvíte se, jak s pomocí šifrování ochránit nejenom data, která ukládáte do databáze, ale také údaje, které odesíláte v URL adrese. V kapitole 26 vám ukážeme, jak se můžete zapojit do bezpečnostního modelu ASP. NET tím, že si vytvoříte vlastního poskytovatele členství.

•

Část V – Pokročilé uživatelské rozhraní. Zde vám ukážeme, jak se dají pomocí vyspělých technik rozšiřovat webové stránky. V kapitolách 27 a 28 se budete potýkat s vlastními ovládacími prvky.

V kapitolách 29 a 30 si obohatíte své dovednosti o JavaScript (pro vytvoření více dynamických stránek), a GDI+ (pro ruční tvorbu obrázků). V kapitole 31 prozkoumáte pracovní rámec pro webové části, s jejichž pomocí se vytvářejí webové portály.

•

Část VI – Webové služby. Webové služby se využívají v oblasti, která se zabývá sdílením funkcionality mezi různými aplikacemi, síťovými prostředími a počítačovými platformami. V kapitole

27 32 začnete úplně na začátku – uvidíte, jak se vytvářejí základní webové služby a jak se používají ve webových aplikacích ASP.NET, v aplikacích .NET Windows, a dokonce ve zděděných aplikacích klasického ASP. V kapitole 33 nahlédnete do nitra standardů, které to všechno umožňují, a uvidíte, jak fungují. V kapitole 34 se dozvíte, jak se prostřednictvím vyspělých technik asynchronně volají webové služby, jak se implementují bezpečné služby, a pomocí soupravy nástrojů WSE (Web Services Enhancements) začnete pracovat s nejnovějšími standardy webových služeb.

Komu je kniha určena?

Kniha je zamýšlena jako prvotní zdroj informací pro profesionální vývojáře, kteří mají slušné znalosti o webovém vývoji na straně serveru. Kniha neposkytuje vyčerpávající pohled na každou ingredienci nacházející se uvnitř .NET Frameworku – taková kniha by musela mít více než dvojnásobný počet stran. Proto se kniha raději zaměřuje na to, aby poskytla neobšírný, inteligentní úvod do ASP.NET pro profesionální programátory, kteří se nemíní zdržovat se základy. Průběžně se budete soustřeďovat na různá zákoutí .NET Frameworku, která potřebujete znát, abyste mohli budovat profesionální webové aplikace, mezi něž které patří přístup k datům a XML. S těmito schopnostmi budete schopni vytvářet weby nové generace, a to s nejlepšími nástroji, jaké jsou dnes k dispozici.

Kniha je také velmi praktická. Nedozvíte se pouze o schopnostech ASP.NET, dozvíte se také o technikách ze skutečného světa, s jejichž pomocí budete moci převést svůj web na vyšší kvalitativní úroveň. Pozdější kapitoly knihy jsou zasvěcené břitkým tématům, jako jsou vlastní ovládací prvky, dynamická tvorba grafiky, pokročilá bezpečnost, či vysoký výkon při přístupu k datům. Tohle všechno je potřebné pro vývoj profesionálních webových aplikací.

Abyste mohli z této knihy vytěžit co nejvíc, měli byste se dobře vyznat v syntaxi jazyka C# a v pojmech objektově orientovaného programování. Nemusíte mít zkušenosti s předchozí verzí ASP.NET, protože veškeré potřebné základy se v knize probírají. Jste-li ostříleným vývojářem Java nebo C++, ale bez zkušeností s .NET, zvažte, zdali byste neměli tuto knihu doplnit nějakým úvodem do .NET, jako je například kniha A Programmer’s Introduction to C# 2.0, Third Edition (Apress, 2005).

Co potřebujete, abyste mohli s knihou pracovat?

Hlavním požadavkem pro práci s touto knihou je nějaký počítač s nainstalovaným Visual Studiem 2005. Přestože se teoreticky dá kód vytvářet ručně, je to nesmírně pracné, a navíc je tu vysoká pravděpodobnost vzniku chyb, takže se tento přístup nikdy nepoužívá v profesionálních kruzích.

POZNÁMKA Je možné používat okleštěnou verzi Visual Studia s označením Web Developer 2005 Express Edition, ale u některých příkladů se dostanete do značných těžkostí. Nejdůležitějším omezením je to, že s Visual Studio Web Developer 2005 Express Edition nemůžete vytvářet knihovny tříd, které jsou podstatnou součástí moderního designu orientovaného na komponenty.

Abyste mohli provozovat stránky ASP.NET, potřebujete Windows 2000 Professional, Windows XP Professional, Windows 2000 Server, nebo Windows Server 2003. Musíte také nainstalovat IIS (Internet Information Services), hostitelský software pro weby, který je součástí operačního systému Windows, a který potřebujete, pokud chcete vytvářet webové služby nebo testovat vaše webové aplikace.

Do knihy je také začleněno několik příkladů, které pracují s ukázkovou databází SQL Serveru, aby bylo možné demonstrovat kód pro přístup k datům, techniky týkající se bezpečnosti, a webové služby. Používáte-li jiné

28 relační databázové enginy, budete moci aplikovat stejné pojmy – ovšem s tím, že budete muset modifikovat zdrojový kód ukázek.

Kniha byla vytvořena s poslední verzí beta 2. Protože ASP.NET v době vydání této knihy dokončovalo svůj vývojový beta cyklus, je možné, že ve finálním vydání dojde k nějakým změnám. Tyto změny mohou zahrnovat nové schopnosti nebo drobné syntaktické odlišnosti (přejmenování nějaké vlastnosti či metody). Protože vám chceme pomoci vyhnout se případným zmatkům, odkazujeme vás na adresu http://www.zonerpress. cz/download/asp_net_2.zip, odkud si můžete moci stáhnout kód ukázek připravený pro finální verzi.

Sdělte nám svůj názor Jako čtenáři této knihy se stáváte těmi nejdůležitějšími kritiky a komentátory. Vážíme si vašeho názoru a chtěli bychom vědět, co děláme správně, co bychom mohli dělat lépe, ve kterých oblastech bychom měli publikovat a také vaše další podnětné myšlenky, o které jste ochotni se s námi podělit.

Jako odborný redaktor Zoner Press vítám vaše názory. Můžete mi psát – poslat e-mail nebo dopis – a sdělit mi, co se vám v této knize líbilo nebo nelíbilo, stejně tak, co bychom měli udělat, aby naše další knihy byly lepší. Pokud mi napíšete, nezapomeňte prosím připojit název knihy, ISBN, jméno autora, vaše jméno, telefon, fax nebo e-mail. Pozorně zhodnotím vaše názory a poskytnu je autorovi a redaktorům, kteří pracovali na této knize.

Prosím, vězte, že nemohu pomoci s technickými problémy, které se týkají obsahu knihy, a že díky velkému množství e-mailů, které dostávám, nemohu zaručit odpověď na každou zprávu.

E-mail: miroslav.kucera@zoner.com nebo knihy@zoner.cz.

Adresa: Zoner Press, ZONER software, s.r.o, Miroslav Kučera, Nové sady 18, 602 00 Brno.

Zdrojové soubory Zdrojové soubory k této knize je možné stáhnout na adrese http://www.zonerpress.cz/download/ asp_net_2.zip (1,92 MB). Zdrojové soubory jsou rozděleny do samostatných adresářů podle kapitol. Než začnete se zdrojovým kódem pracovat, přečtěte si doprovodný soubor readme.txt, který obsahuje informace o tom, co je potřeba mít na zřeteli.

KAPITOLA 1 Úvod do ASP.NET Když ve společnosti Microsoft vytvářeli .NET, nesnili pouze o budoucnosti – na srdci jim také ležely různé neduhy a omezení současné generace technologií webového vývoje. Než začneme pracovat s ASP.NET 2.0, neuškodí, když se trochu poohlédneme zpět, a budeme se chvilku těmto problémům věnovat. Pak lépe pochopíte, jaké nabízí .NET možnosti.

V této kapitole probereme historickou cestu, kterou urazil webový výzkum, a která nás dovede až k ASP.NET. Prolétneme tryskem okolo nejvýznamnějších rysů .NET a zběžně se seznámíme s klíčovými změnami, které přicházejí s ASP.NET 2.0. Jestliže s ASP.NET začínáte, pomůže vám tato kapitola, abyste se rychle dostali do obrazu. Jste-li však příležitostným vývojářem v .NET, máte dvě možnosti. Tou první je, že si kapitolu přečtete, abyste bryskně získali přehled o tom, jak to s ním vypadá dnes. Druhá možnost je taková, že rovnou přejdete k oddílu "ASP.NET 2.0 – příběh pokračuje", abyste se seznámili s tím, co má ve svém arzenálu ASP.NET 2.0.

Evoluce webového vývoje První přenos dat přes HTTP (Hypertext Transfer Protocol) uskutečnil Tim Berners-Lee už před více než deseti lety. Od té doby prodělalo HTTP exponenciální růst popularity, prolomilo hranice malé skupiny vizionářů počítačové vědy, a pronikl jak do soukromého sektoru, tak i do byznysu. Dnes je to téměř slovo patřící do běžného hovorového jazyka.

Když bylo HTTP zřízeno poprvé, bylo pro vývojáře nelehkou výzvou navrhovat aplikace, které se uměly vyhledat a vzájemně spolu komunikovat. Aby mohli vývojáři takové výzvě úspěšně čelit, byly pro ně vytvořeny různé standardy, jako HTML (Hypertext Markup Language) nebo XML (Extensible Markup Language).

HTML definovalo prostý jazyk, s jehož pomocí je možné popsat, jak zobrazit komplikované dokumenty na prakticky jakékoliv počítačové platformě. XML zase vytvořilo sadu pravidel pro vytváření formátů dat neutrálních vzhledem k platformám, s jejíž pomocí si pak mohou rozličné aplikace vyměňovat informace. Standardy garantovaly, že web mohl od té doby využívat kdokoliv, odkudkoliv, a s jakýmkoliv typem počítačového systému.

Souběžně s tím výrobci softwaru čelili svým vlastním výzvám. Potřebovali vyvinout nejenom takové jazyky a programovací nástroje, které by uměly komunikovat s webem, ale také celý pracovní rámec, které by vývojářům umožnil navrhovat nejenom architekturu aplikací, ale také je vyvíjet a rozšiřovat – a to, pokud možno, co nejsnadnějším způsobem. Přední výrobci softwaru, IBM, Sun Microsystems či Microsoft, spěchali, aby vzniklou potřebu uspokojili hromadou nových produktů.

32

Kapitola 1 – Úvod do ASP.NET

ASP.NET 1.0 otevřel novou kapitolu ve stále probíhajícím závodě ve zbrojení. Společnost Microsoft s technologií .NET vytvořila integrovanou skupinu komponent, která kombinuje budování částí pro web (značkovací jazyky a HTTP) s osvědčenou metodologií orientovanou na objekty.

Vývojový svět před příchodem ASP.NET Starší technologie určené pro webové aplikace založené na serveru se spoléhaly na skriptovací jazyky, nebo na proprietární konvence značkování. Většina modelů pro webový vývoj poskytovala jen nemotorné háky, s jejichž pomocí jste mohli spouštět aplikace nebo nechat běžet komponenty na serveru. Neposkytovaly moderní a integrovaný pracovní rámec (framework) pro webové programování.

Obecně se dá říci, že většina pracovních rámců pro webový vývoj, které byly vytvořeny před ASP.NET, spadá do jedné ze dvou kategorií:

• •

Skripty, které interpretuje nějaký zdroj na serveru.

Oddělené, malinkaté aplikace, které se vykonávají voláním na straně serveru.

Klasické ASP (Active Server Pages, verze ASP, která je předchůdcem ASP.NET) a ColdFusion patří do první kategorie. Vy, jakožto vývojář, máte za úkol vytvořit soubor se skriptem, který obsahuje vložený kód. Soubor skriptu prozkoumá jiná komponenta, která střídá zpracování běžného HTML kódu a vykonávání vašeho vloženého kódu. Jestliže jste už někdy vytvářeli aplikace ASP, bezpochyby je vám známo, že skriptované aplikace se vykonávají mnohem menší rychlostí, než aplikace zkompilované. Skriptované platformy mimo to podporují vznik dodatečných problémů – chybí například možnost řídit nastavení bezpečnosti nebo se neefektivně využívají systémové zdroje.

Druhý přístup, který ve značné míře využívá Perl přes CGI (Common Gateway Interface), přináší zase úplně odlišnou sadu problémů. V těchto pracovních rámcích spouští webový server oddělenou aplikaci, která má za úkol zpracovat požadavek klienta. Aplikace vykonává svůj kód a dynamicky vytváří HTML, který se má poté odeslat zpět klientovi. Přestože se aplikace tohoto druhu vykonávají rychleji než jejich skriptované protějšky, vykazují tendenci spotřebovávat mnohem více paměti. Klíčovým problémem je to, že webový server musí vytvořit oddělenou instanci aplikace pro každý požadavek klienta. Takový model způsobuje, že aplikace jsou mnohem méně škálovatelné (scalable) v prostředích s velkým počtem simultánních uživatelů – zejména tehdy, pokud neprogramujete velmi pečlivě. Tento druh aplikací se dost obtížně píše, dost obtížně ladí, a navíc není snadné je integrovat s jinými komponentami.

ASP.NET znamená mnohem víc než prostou evoluci jednoho či druhého typu aplikace. Boří stávající trend a přichází s kompletně novým vývojovým modelem. Hlavní rozdíl je v tom, že ASP.NET je do hloubky integrováno se svým podkladovým pracovním rámcem. ASP.NET není nějaké rozšíření či modifikace .NET Frameworku s elastickými háky napojenými do funkcionality, kterou poskytuje. Je to zcela jinak. ASP.NET je částí .NET Frameworku, kterou spravuje runtime .NET. Technologie ASP.NET v podstatě odstraňuje dělící čáru mezi vývojem aplikací a webovým vývojem, protože rozšiřuje nástroje a technologie, které si výhradně používali vývojáři desktopových aplikací, do světa webového vývoje.

Co je špatného na klasickém ASP? Jestliže jste doposud programovali s klasickým ASP, možná se divíte, proč bylo Microsoftem v ASP.NET změněno úplně všechno. Naučit se úplně nový pracovní rámec, to rozhodně není dětská slavnost, zvláště tehdy, když .NET přichází s hromadou nových pojmů a nabízí některé části, jejichž zvládnutí může být dosti zapeklitou záležitostí.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

33

Všeobecně se dá říci, že klasické ASP je solidním nástrojem pro vývoj webových aplikací s využitím technologií Microsoftu. Ovšem, podobně jako je tomu u většiny vývojových modelů, ASP sice některé problémy řeší, nicméně také přináší několik nových problémů. V následujících částech si tyto problémy stručně popíšeme.

Kód, co se táhne jako špagety Pokud jste někdy vytvářeli aplikace s ASP, pravděpodobně jste se setkali s dlouhými stránkami, které obsahují směs skriptu realizovaného na straně serveru a HTML. Podívejte se na ukázku. Kód v ní uvedený naplňuje rozevírací seznam (ovládací HTML prvek) výsledky získanými databázovým dotazem: <% Set dbConn = Server.CreateObject("ADODB.Connection") Set rs = Server.CreateObject("ADODB.Recordset") dbConn.Open connectionString %> <select name="cboAuthors"> <% rs.Open "SELECT * FROM Authors", dbConn, 3, 3 Do While Not rs.EOF %> <option value="<%=rs("au_id")%>"><%=rs("au_lname") & ", " & _ rs("au_fname")%></option> <% rs.MoveNext Loop %> </select>

V této ukázce je zapotřebí celých 16 řádků kódu na to, aby se vygeneroval jediný ovládací HTML prvek. To není zrovna působivé. Horší ale je, že takový styl psaní kódu má negativní dopad na výkon aplikace, protože se dohromady míchá HTML a skript. Až bude tuhle stránku zpracovávat ISAPI (Internet Server Application Programming Interface) ASP, což je rozšíření, které běží na webovém serveru, bude se muset skriptovací engine několikrát zapínat a vypínat, a přitom se jedná o zpracování jednoho jediného požadavku. Zvyšuje se tím doba nutná na zpracování celé stránky a její odeslání klientovi.

Dále, webové stránky, které jsou napsané pomocí tohoto stylu, mohou snadno a rychle nabobtnat do nezvladatelných délek. A přidáte-li do celé skládačky ještě vaše vlastní komponenty COM, které budete potřebovat na zprovoznění funkcionalit, které ASP poskytnout neumí, stane se noční můra ohledně údržby takových stránek ještě tíživější. Závěr je jasný. Bez ohledu na to, jaký přístup zvolíte, kód ASP vykazuje tendenci, že se postupně stane odpudivým, nadměrně dlouhým, a neuvěřitelně obtížně laditelným – pokud ovšem dokážete nějaké ladění ASP ve vašem prostředí vůbec zprovoznit.

V ASP.NET takové problémy neexistují. Webové stránky se píší s ohledem na tradiční objektově orientované pojmy, a obsahují takové ovládací prvky, že s nimi pracujete velmi obdobným způsobem jako v případě desktopových aplikací. To znamená, že nemusíte dělat směs z HTML značek a přímého (inline) kódu. Pokud přijmete při vytváření stránek ASP.NET přístup, kdy se používá kód v pozadí (code-behind), bude kód opravdu oddělen od prezentace, což zjednoduší údržbu kódu a umožní oddělit design webové stránky od obtížné práce spojené s vytvořením kódu pro webové stránky.

34

Kapitola 1 – Úvod do ASP.NET

Skriptovací jazyky V době, kdy bylo vytvořeno, vypadalo ASP jako perfektní řešení pro desktopové vývojáře, kteří se přesouvali do světa webu. Místo toho, aby se museli učit nějaký úplně nový jazyk, nebo novou metodologii, jim ASP umožnilo, aby použili jim důvěrně známé jazyky, jako VBScript, na programovací platformě založené na serveru. Protože se už tehdy jako podkladová kostra používal populární programovací model COM (Component Object Model), skriptovací jazyky fungovaly i jako pohodlný dopravní prostředek pro přístup ke komponentám a prostředkům serveru. Ale i když bylo ASP snadno pochopitelné pro vývojáře, kteří dovedně ovládali skriptovací jazyky, jako je VBScript, tahle důvěrná známost nebyla získána zadarmo. Protože ASP bylo založeno na starších technologiích, které byly původně navrženy pro použití u klientů, nemohly stejně dobře fungovat v novém prostředí webového vývoje.

Výkon nebyl jediným problémem. Každý objekt nebo proměnná, které byly použity v klasickém skriptu ASP, se vytvářely jako datový typ variant. Většina programátorů Visual Basicu velmi dobře ví, že datové typy variant jsou velmi vágně typované. Požadují větší množství paměti a jsou pozdě vázány (late-bound) – výsledkem je nižší výkon. Kompilátor a vývojové nástroje navíc nemohly tyto datové typy identifikovat v době generování designu. To způsobilo, že bylo téměř nemožné vytvořit opravdu integrované vývojové prostředí (IDE, integrated development environment), které by poskytlo programátorům ASP cokoliv podobného, jako jsou třeba vyspělé ladicí prostředky, IntelliSense, nebo kontroly chyb, což jsou věci běžné ve Visual Basicu a Visual C++. Bez ladicích nástrojů na odpovídající úrovni se programátoři ASP dostávali do těžkých stresů, když měli napravovat chyby, které vznikaly v jejich skriptech.

ASP.NET všechny takové problémy obchází velkým obloukem. Pro začátek stačí říct, že se stránky a webové služby ASP.NET vykonávají uvnitř CLR (common language runtime), takže mohou být napsány v jakémkoliv jazyku, pro který existuje kompilátor, který funguje v souladu s požadavky CLR. Už nejste omezeni pouze na VBScript nebo JavaScript – můžete používat i moderní objektově orientované jazyky, jako jsou Visual Basic a C#.

Je také důležité připomenout, že stránky ASP.NET se neinterpretují, ale kompilují do tzv. assembly, což je termín .NET pro jakoukoliv jednotku zkompilovaného kódu). Jedná se o jeden z nejvýznamnějších zobecňujících příspěvků do webového vývojového modelu Microsoftu. To, co se skutečně děje za scénou, je opravdu revoluční. I když třeba vytvoříte svůj kód v Poznámkovém bloku a zkopírujete ho přímo do nějakého virtuálního adresáře na webovém serveru, aplikace se dynamicky zkompiluje, jakmile k ní přistoupí nějaký klient, a její kopie se uloží do cache pro potřeby budoucích požadavků. Jestliže se po ukončení kompilačního procesu kterýkoliv ze souborů změní, aplikace se automaticky překompiluje, jakmile ji bude nějaký klient vyžadovat.

Smrt COM Přestože Microsoft hlásá věčnou podporu pro COM, což je technologie, která tvoří základ operačního systému Windows a téměř každé aplikace, která pod ním běží, je zřejmé, že .NET je pro moderní vývoj počátkem nové cesty. Budoucí verze operačního systému Windows (včetně nepolapitelného Longhornu) budou do jádra operačního systému stále více integrovat .NET Framework, což z něho učiní prvotřídní jazyk pro veškerý vývoj aplikací. A tak, jak budou aplikace COM postupně ztrácet na popularitě a převádět se do .NET, klasické ASP se časem stane pouhou vzpomínkou na minulost. Přestože .NET zahrnuje robustní podporu součinnosti s COM, faktem zůstává, že pro klasické aplikace ASP už není ve světě .NET místo.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

35

ASP.NET 1.0 Vývojáři Microsoftu popsali ASP.NET jako svou šanci "odeslat příkaz pro zformátování systému", a začít ze zcela novým a modernějším vývojovým modelem. Tradiční pojmy týkající se vytváření webových aplikací však ve světě .NET stále platí. Každá webová aplikace se skládá z webových stránek. Můžete zpracovávat bohatě vybavené HTML, používat JavaScript, vytvářet komponenty, do nichž zapouzdříte programovací logiku, nebo přizpůsobovat a vylaďovat své aplikace za pomoci různých konfiguračních voleb. V pozadí však ASP.NET pracuje zcela odlišně než tradiční skriptovací technologie, mezi které patří klasické ASP nebo PHP. ASP.NET je také mnohem více ambicióznější než JSP (JavaServer Pages).

ASP.NET se v porovnání s dřívějšími vývojovými platformami odlišuje v těchto věcech:

•

ASP.NET nabízí úplný, objektově orientovaný programovací model, který obsahuje architekturu řízenou událostmi, založenou na ovládacích prvcích, což podporuje zapouzdřování kódu a jeho opětovné využívání.

•

ASP.NET dává možnost psát kód v kterémkoliv z podporovaných jazyků.NET (mezi ně patří Visual Basic, C#, J# a mnoho dalších jazyků, které mají kompilátory od jiných výrobců).

•

ASP.NET slouží také jako platforma pro budování webových služeb, což jsou opětovně využitelné jednotky kódu, které mohou volat jiné aplikace přes platformy a hranice dané počítači. Webová služba se dá použít prakticky na cokoliv – od zpřístupnění desktopové aplikace na webu až třeba po sdílení dat s klientem Javy běžícím pod Unixem.

•

ASP.NET je vše podřízeno vysokému výkonu. Stránky ASP.NET a komponenty se kompilují na požádání, a tudíž se neinterpretují pokaždé, když se použijí. ASP.NET také obsahuje vyladěný model pro přístup k datům a flexibilní ukládání dat do cache, aby bylo možné ještě více zvyšovat výkon v případě potřeby.

Tohle je pouze několik ze základních rysů, mezi které dále patří rozšířená správa stavu (state management), praktické vázání dat, dynamická tvorba grafiky nebo robustní model bezpečnosti. S jednotlivými zdokonaleními se podrobně seznámíte v knize a zjistíte, jak do celého obrázku zapadá ASP.NET 2.0.

Sedm důležitých faktů o ASP.NET Jestliže s ASP.NET začínáte (nebo si prostě chcete osvěžit nějaké základy), budou pro vás následující oddíly zajímavé. Uvádí se v nich sedm nejdůležitějších faktů o .NET.

Fakt 1: ASP.NET je integrováno s .NET Frameworkem .NET Framework je rozčleněn do kolekce funkčních částí, zahrnující více než 7000 typů (termín .NET pro třídy, struktury, rozhraní a další klíčové programovací ingredience). Než se můžete pustit do programování jakéhokoliv druhu aplikace .NET, je potřeba, abyste měli základní informace o těchto částech – a abyste chápali, proč jsou věci uspořádány tak, jak uspořádány jsou.

Obrovská kolekce funkcionality, kterou poskytuje .NET Framework, je zorganizována tak, že klasičtí programátoři Windows to budou považovat za šťastný krok vpřed. Každá z těch tisíců tříd v .NET Frameworku je seskupena do logického, hierarchického kontejneru, který se nazývá jako jmenný prostor (namespace).

Různé jmenné prostory poskytují různé schopnosti. Když se to vezme všechno dohromady, tak jmenné prostory .NET nabízejí funkcionalitu téměř jakéhokoliv aspektu distribuovaného vývoje, od front zpráv (message queuing) až po otázky bezpečnosti. Této obrovské skupině nástrojů se říká knihovna tříd (class library).

36

Kapitola 1 – Úvod do ASP.NET

Je zajímavé, že třídy .NET Frameworku používáte v ASP.NET stejně, jako v jakémkoliv jiném druhu aplikace .NET (mezi které patří různé aplikace Windows, služby Windows, utility pro příkazový řádek atd.). Jinak řečeno – .NET dává webovým vývojářům stejné nástroje, jaké dává vývojářům bohatě vybavených klientských aplikací.

Jestliže jste už něco s ASP.NET 1.x naprogramovali, zjistíte, že stejná sada tříd je k dispozici i v ASP.NET 2.0.

Rozdíl je v tom, že ASP.NET 2.0 přidává do připraveného koktejlu ještě další třídy; mnohé z nich jsou ve zcela nových jmenných prostorech, které jsou určené pro speciální činnosti, kam například patří konfigurace, monitorování zdravotního stavu (health monitoring) nebo personalizace.

TIP Jedním z nejlepších zdrojů, v němž se dozvíte o všech nových zákoutích .NET Frameworku, je jeho referenční příručka knihovny tříd (.NET Framework class library reference), která je součástí referenční knihovny MSDN Help. Máte-li nainstalované Visual Studio 2005, dostanete se do knihovny MSDN Help tak, že zvolíte Start > Programy > Microsoft Visual Studio 2005 > Microsoft Visual Studio 2005 Documentation (přesný text prvků menu závisí na vaší konkrétní verzi Visual Studia). Jakmile jednou nápovědu načtete, referenční informace o třídách naleznete uspořádané podle jmenných prostorů pod uzlem .NET Development > .NET Framework SDK > Class Library Reference.

Fakt 2: ASP.NET se neinterpretuje, ale kompiluje Jedním z hlavních důvodů degradace výkonu ve skriptech ASP je to, že se v kódu webových stránek ASP používají interpretované skriptovací jazyky. To znamená, že když se aplikace vykonává, musí skriptovací hostitel na serveru interpretovat kód a přeložit jej do strojového kódu nižší úrovně, pěkně řádek po řádku. Tento proces je, jak každý ví, velmi pomalý.

POZNÁMKA V tomto případě je reputace o něco horší než skutečnost. Interpretovaný kód je nepochybně pomalejší než zkompilovaný kód, ale rozdíl ve výkonu není až tak signifikantní, aby to způsobovalo, že byste s ASP nemohli vytvářet profesionální weby. Stejná omezení, která v tomto ohledu ovlivňují ASP, ovlivňují i aplikace Javy, protože Java je také interpretovaný jazyk, který se nikdy nekompiluje. Je to jeden z dramatických rozdílů mezi Javou a jazyky, které budete používat při práci s ASP.NET.

Aplikace ASP.NET se kompilují vždy – a skutečně, je nemožné spouštět kód C# nebo VB.NET, aniž by se předtím nejprve nezkompiloval.

Aplikace ASP.NET procházejí dvěma kompilačními etapami. V první etapě se kód C#, který jste napsali, zkompiluje do přechodného jazyka, který se nazývá jako Microsoft Intermediate Language (MSIL), nebo prostě jen IL. Tento první krok je fundamentální příčinou toho, že v .NET je možné používat různé programovací jazyky. Všechny jazyky .NET (včetně C#, Visual Basicu, a mnoha dalších) se totiž zkompilují do virtuálně identického kódu IL. První kompilační krok může nastat automaticky, když se stránka poprvé požaduje, nebo se může vykonat předem (to je proces, kterému se říká předběžná kompilace, precompiling). Zkompilovanému souboru s kódem IL se říká assembly.

Druhá úroveň kompilace nastává těsně předtím, než se stránka skutečně vykoná. V tomto okamžiku se kód IL zkompiluje do nativního nízkoúrovňového strojového kódu. Tato etapa se nazývá jako kompilace just-in-time (JIT) a probíhá stejně pro všechny aplikace .NET (včetně například aplikací Windows). Oba kroky kompilačního procesu vidíte na obrázku 1-1.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

37

Kompilace .NET je rozdělena do dvou kroků proto, aby se vývojářům mohlo nabídnout co největší pohodlí a co nejlepší přenositelnost. Předtím, než může kompilátor vytvořit nízkoúrovňový strojový kód, potřebuje znát typ operačního systému a hardwarovou platformu, kde bude aplikace běžet (například 32bitový nebo 64bitový operační systém Windows). Když máte dvě kompilační etapy, můžete vytvořit zkompilovanou assembly s kódem .NET, kterou je možné distribuovat na více než jednu platformu.

Kód ve VB.NET

Kompilátor VB .NET

Kód v C#

Kód v jiném jazyku .NET

Kompilátor C#

Adekvátní kompilátor

Kód v C#

Spoleèný runtime jazyk (Common Language Runtime)

Kompilátor JIT (Just-in-time)

Nativní strojový kód

Vykonání kódu

Obrázek 1-1. Kompilace webové stránky ASP.NET.

POZNÁMKA Brzy přijde den, kdy tento model možná pomůže profesionálním programátorům v rozšiřování aplikací na operační systémy, které nejsou od Microsoftu, jako je třeba Linux. Tento ambiciózní cíl sice doposud nebyl uskutečněn, ale pokud byste si rádi vyzkoušeli první verzi .NET pro platformu Linux (s vývojovou implementací ASP.NET), navštivte http://www.go-mono.com a stáhněte si nejnovější verzi tohoto softwaru pocházejícího od komunity open-source.

Kompilace JIT by samozřejmě nebyla tak užitečná, kdyby se musela provádět pokaždé, když nějaký uživatel požádá o zobrazení nějaké webové stránky. Aplikace ASP.NET se naštěstí nemusejí kompilovat pokaždé, když vznikne nějaký požadavek na webovou stránku či webovou službu. Kód IL se vytvoří pouze jednou, a pak už se generuje jen tehdy, když dojde k modifikaci zdroje. Obdobně se uchovávají i kopie souborů s nativním

Kapitola 1 – Úvod do ASP.NET

38

strojovým kódem, a sice v systémovém adresáři, jehož cesta typicky vypadá jako c:\[WinDir]\Microsoft.NET\ Framework\[Verze]\Temporary ASP.NET Files, kde [WinDir] zastupuje adresář Windows a [Verze] zastupuje číslo aktuálně nainstalované verze .NET Frameworku.

POZNÁMKA Přestože jsou počítačové testy výkonnosti hodně kontroverzní, zajímavé porovnání Javy a ASP.NET najdete na http://gotdotnet.com/team/compare. Mějte ale na paměti, že skutečné nesnáze omezující výkon se obvykle vztahují ke konkrétním "úzkým hrdlům" systému, jakými jsou například rychlost přístupu na disk, využívání CPU, rychlost síťového připojení atd. V mnoha testech výkonnosti vykazuje ASP.NET lepší výsledky než jiná řešení, protože podporuje ty schopnosti platforem, které mají vliv na výkon, například ukládání dat do cache. Není to následek nárůstu rychlosti způsobeného tím, že je kód zkompilovaný.

Přestože v ASP.NET 2.0 zůstává kompilační model v podstatě stejný, jedna důležitá změna tu je. Vývojářský nástroj (Visual Studio) už kód nekompiluje. Webové stránky a služby se kompilují až tehdy, když je poprvé spustíte, což má pozitivní dopad na proces ladění. Abyste se vyhnuli zbytečné zátěži s první kompilací, když rozmisťujete finální aplikaci (a zabránili jiným lidem šťourat se ve vašem kódu), můžete využít novou schopnost předběžné kompilace (precompilation), která se blíže vysvětluje v kapitole 18.

Fakt 3: ASP.NET je vícejazyčné I když při vývoji svých aplikací patrně dáváte přednost jednomu z jazyků před ostatními, tahle volba neurčuje, co budete všechno schopni udělat ve vašich webových aplikacích. Je to proto, že ať už použijete kterýkoliv jazyk, kód se vždy zkompiluje do IL. IL je odrazovým můstkem každé řízené aplikace. (Řízená aplikace, managed application, je jakákoliv aplikace, která byla napsána pro .NET a vykonává se uvnitř řízeného prostředí CLR.) V jistém smyslu je jazykem .NET právě IL. Je to jediný jazyk, kterému CLR rozumí.

Abyste IL snadněji pochopili, ukažme si jednoduchý příklad. Podívejme se na jednu funkci, která byla napsaná v jazyku C#: namespace HelloWorld { public class TestClass { private static void Main(string[] args) { Console.WriteLine("Hello World"); } } }

Kód předvádí nejjednodušší aplikaci, jakou lze v .NET napsat – je to jednoduchá utilita pro příkazový řádek, která zobrazí v okně konzole jedinou, předem stanovenou, zprávu.

Nyní se podívejme na tento kód z jiné perspektivy. Tady máte odpovídající kód IL: .method public static void Main() cil managed { .entrypoint

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

39

.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) // Code size 14 (0xe) .maxstack 8 IL_0000: nop IL_0001:

ldstr "Hello World"

IL_0006:

call void [mscorlib]System.Console::WriteLine(string)

IL_000b: nop IL_000c: nop IL_000d: ret } // konec metody Module1::Main

K IL kódu jakékoliv zkompilované aplikace .NET se dostanete velmi snadno. Spustíte prostě Disassembler IL, který se nainstaluje společně s Visual Studiem a .NET SDK (Software Development Kit).

Soubor ildasm.exe hledejte v adresáři, který mívá obvykle cestu c:\Program Files\Visual Studio 2005\SDK\ v2.0\Bin. Jakmile tento program načtete, zvolte File > Open a k prohlížení si vyberte libovolný soubor DLL nebo EXE, který byl vytvořen s .NET. Pokud chcete zjistit, co se v IL kódu děje, a pokud budete trpěliví, dokážete s trochou logiky takový kód IL snadno dešifrovat. Skutečnost, že se dá IL snadno rozkrýt, může sice vyvolávat otázky, jak moc je vlastně soukromý a jak lze nad ním získat plnou kontrolu, nicméně těmito záležitostmi se obvykle vývojáři ASP. NET vůbec nezabývají. A to proto, že veškerý kód ASP.NET se ukládá i vykonává na serveru. Protože soubor se zkompilovaným kódem klient nikdy neobdrží, nemá žádnou možnost, jak ho dekompilovat. Jestliže vás ale tahle záležitost přece jenom trápí, použijte nějakou "zatemňující" utilitu, neboli obfuscator, který kód "zamlží", takže bude obtížnější mu porozumět. (Můžete například přejmenovat všechny proměnné tak, aby měly nesmyslné, o ničem nevypovídající, názvy jako třeba f__a__234.). Visual Studio obsahuje zredukovanou verzi jednoho obfuscatoru, který se jmenuje Dotfuscator.

Následující výpis obsahuje kód téže utility pro příkazový řádek, tentokrát ve Visual Basicu: Namespace HelloWorld Public Class TestClass Private Shared Sub Main(Ars() As String) Console.WriteLine("Hello World") End Sub End Class End Namespace

Pokud byste zkompilovali tuto aplikaci a podívali se na kód IL, zjistili byste, že všechny jeho řádky jsou identické s kódem IL, který se vygeneroval z verze v jazyku C#. Přestože jednotlivé kompilátory mohou tu a tam vnášet své vlastní optimalizace, všeobecným pravidlem je, že žádný z jazyků .NET nepodává lepší výsledky než jiný jazyk .NET, protože všechny sdílejí společnou infrastrukturu. Tato infrastruktura je definována ve specifikaci společného jazyka (CLS, Common Language Specification), kterou popisujeme v rámečku "Specifikace společného jazyka" dále v textu.

Je důležité připomenout, že IL byl nedávno přijat jako standard ANSI (American National Standards Institute). Toto přijetí by mohlo urychlit přijetí ostatních pracovních rámců společného jazyka (common language frameworks). Jako ukázka jednoho z takových projektů může posloužit projekt Mono, který je k dispozici na adrese http://www.go-mono.com.

40

Kapitola 1 – Úvod do ASP.NET

SPECIFIKACE SPOLEČNÉHO JAZYKA CLS definuje standardní vlastnosti, které musejí obsahovat všechny objekty, aby spolu mohly v nějakém homogenním prostředí vzájemně komunikovat. Aby mohl CLR takovou komunikaci umožnit, očekává, že všechny objekty budou ctít konkrétní sadu pravidel.

Touto sadou pravidel je CLS. Definuje mnoho norem, které musejí jazyky dodržovat, jako klíčová slova, typy, přetěžování metod (overloading) atd. Každý kompilátor generující kód IL, který se má vykonat v CLR, musí ctít všechna pravidla vyžadovaná uvnitř CLS. CLS dává vývojářům, dodavatelům a výrobcům softwaru možnost pracovat uvnitř společné sady specifikací stanovených pro jazyky, kompilátory a datové typy. Postupem času se bude vynořovat víc a víc jazyků a kompilátorů, které budou v souladu s požadavky CLS, několik takových už je dnes k dispozici.

Vezmeme-li v potaz stanovená kritéria, může být dost složité vytvořit kompilátor jazyka, který by generoval kód tak, aby byl plně v souladu s požadavky CLR. Nicméně, kompilátory mohou existovat pro prakticky jakýkoliv jazyk, a je zde šance, že nějaký vyhovující kompilátor bude k dispozici pro každý z jazyků, o jehož použití byť jenom vzdáleně uvažujete. Představte si – programátoři sálových počítačů, kteří kdysi nedali dopustit na COBOL, protože jej považovali za výkvět všech jazyků, mohou nyní své znalosti uplatnit při vytváření webových aplikací.

Fakt 4: ASP.NET běží uvnitř společného runtime jazyků Patrně nejdůležitějším aspektem ASP.NET, který je potřeba si zapamatovat, je to, že běží uvnitř runtime enginy CLR. Na .NET Framework se v celku – tj. se všemi svými jmennými prostory, aplikacemi a třídami – odkazuje jako na řízený (managed) kód. I když vyčerpávající rozbor CLR přesahuje téma této kapitoly, uveďme si alespoň několik výhod, které z toho plynou:

•

Automatická správa paměti a svoz odpadků (garbage collection). Vždy, když aplikace vytvoří instanci nějakého objektu, CLR alokuje pro objekt prostor na řízeném heapu (managed heap). Vy tuto paměť ovšem nikdy nemusíte uvolňovat ručně. Jakmile se vaše reference na objekt dostane mimo obor (nebo aplikace končí), stane se objekt dostupným pro svoz odpadků (garbage collection). Uvnitř CLR pravidelně jezdí (běží) "popelářský vůz" (garbage collector) a automaticky požaduje nepoužívanou paměť objektů, k nimž už nelze přistupovat. Tento model vás zbavuje nutnosti zabývat se složitostmi nízkoúrovňového zacházení s pamětí ve stylu C++ a od podivností spojených s počítáním referencí na COM.

•

Typová bezpečnost. Když kompilujete nějakou aplikaci, .NET přidá do assembly informaci, specifikující některé podrobnosti o ní, například dostupné třídy, jejich členy, jejich datové typy atd.

Výsledkem je, že assembly zkompilovaného kódu budou plně soběstačné. Jiní lidé je budou moci používat, aniž by se požadovaly nějaké podpůrné soubory, nehledě na to, že kompilátor umí ověřit, zdali bude každé volání při běhu platné. Tato dodatečná vrstva bezpečnosti také zamezuje vzniku různých nízkoúrovňových chyb, jako je nechvalně proslulé přetečení bufferu.

•

Rozšiřitelná metadata. Informace o třídách a členech jsou pouze jedním z typů metadat, která .NET ukládá do zkompilované assembly. Metadata popisují kód a umožňují poskytnout dodatečné informace pro runtime nebo pro jiné služby. Metadata mohou například sdělit debuggeru, jak má trasovat kód, nebo mohou sdělit Visual Studiu, jak má zobrazit nějaký váš prvek v režimu designu.

Pomocí metadat můžete také zapnout další služby runtime (jako jsou webové metody nebo služby COM+).

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

41

•

Strukturované zpracování chyb. Jestliže jste někdy napsali jakýkoliv, pro lidi alespoň trochu užitečný kód ve Visual Basicu nebo VBScriptu, téměř jistě jsou vám důvěrně známé omezené prostředky, které tyto jazyky nabízejí pro zpracování chyb. Pomocí strukturovaného zpracování výjimek můžete svůj kód, jímž budete reagovat na chyby, uspořádat logicky, stručně a výstižně. Můžete vytvářet oddělené bloky, v nichž budete zpracovávat různé druhy chyb. Ovladače (handlers) výjimek můžete vnořovat do hloubky, přes více vrstev.

•

Multithreading. CLR poskytuje fond vláken (pool of threads), který mohou využívat různé třídy.

Můžete například volat metody, číst soubory, nebo komunikovat s webovými službami asynchronně, aniž byste museli explicitně vytvářet nové vlákna.

Vysokoúrovňový pohled na CLR a .NET Framework můžete vidět na obrázku 1-2.

Obrázek 1-2. CLR a .NET Framework.

Fakt 5: ASP.NET je objektově orientované ASP poskytuje poměrně chabý objektový model. Poskytuje pouze malou sadu objektů a v podstatě tvoří pouze tenkou vrstvu nad zdrojovými detaily HTTP a HTML. Oproti tomu je ASP.NET opravdu objektově orientované. Nejenom, že kód má úplný přístup ke všem objektům v .NET Frameworku, můžete také těžit z veškerých konvencí objektově orientovaného prostředí (OOP). Můžete například vytvářet opětovně využi-

42

Kapitola 1 – Úvod do ASP.NET

telné třídy, standardizovat kód s rozhraním, nebo začlenit nějakou užitečnou funkcionalitu do zkompilované komponenty určené k šíření.

Jednu z nejhezčích ukázek objektově orientovaného myšlení v ASP.NET naleznete u serverových ovládacích prvků (server-based controls). Serverové ovládací prvky jsou ideálním vzorem pro zapouzdření. Vývojáři mohou s objekty ovládacích prvků programátorsky manipulovat pomocí kódu, např. pro přizpůsobení jejich vzhledu, mohou jim poskytovat data, která zobrazují nebo mohou reagovat na různé události. Nízkoúrovňové detaily HTML jsou ukryty v pozadí. Místo toho, aby byl vývojář nucen ručně vytvářet zdrojový kód HTML, jednotlivé objekty ovládacích prvků se do HTML převedou samy, při realizování stránky. ASP.NET tedy nabízí serverové ovládací prvky jako způsob abstrakce nízkoúrovňových detailů pro programování HTML a HTTP. Podívejte se na krátkou ukázku založenou na standardním textovém poli v HTML: <input type="text" id="myText" runat="server" />

Pouhým přidáním atributu runat="server" se z původní statické části HTML stává plnohodnotný a funkční ovládací prvek na straně serveru, s nímž můžete manipulovat ve svém zdrojovém kódu. Můžete pracovat s událostmi, které generuje, nastavovat atributy nebo vázat ovládací prvek na zdroj dat.

Například text, který se má v tomto prvku objevit při prvním načtení stránky, můžete nastavit tímto jednoduchým kódem: void Page_Load(object sender, EventArgs e) { myText.Value = "Hello World!"; }

Kód po formální stránce nastavuje vlastnost Value objektu HtmlInputText. Výsledkem je, že přiřazený řetězec textu se zobrazí v textovém poli na HTML stránce, která se realizovala a odeslala klientovi.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

43

OVLÁDACÍ PRVKY HTML VERSUS WEBOVÉ OVLÁDACÍ PRVKY Když se ASP.NET vytvářet, existovaly dva možné způsoby vývoje. Někteří vývojáři ASP.NET se nejvíce zajímali o ty serverové ovládací prvky, které by exaktně odpovídaly již existující sadě ovládacích prvků HTML. Tento přístup umožňuje vytvářet rozhraní webových stránek ASP.NET v editorech určených pro editaci HTML, a umožňuje rychlou migraci existujících ASP stránek. Jiná skupina vývojářů ASP.NET však rozpoznala příslib něčeho nového – bohatě vybavených serverových ovládacích prvků, jejichž náplní nebude pouhá emulace jednotlivých HTML značek. Takové ovládací prvky by pak mohly realizovat svá rozhraní z desítek odlišných prvků HTML, ale přitom programátorovi stále poskytovat jednoduché rozhraní založené na objektech. Pomocí tohoto modelu by pak vývojáři mohli pracovat s programovatelnými nabídkami, s kalendáři, s různými seznamy dat nebo s validátory.

Po zralé úvaze se společnost Microsoft rozhodla, že poskytne oba modely. Právě jste viděli ukázku serverového ovládacího prvku HTML, který se mapuje přímo na základní sadu HTML značek. Kromě nich však existují webové ovládací prvky ASP.NET, které poskytují mnohem vyšší úroveň abstrakce a více funkcionality.

Ve většině případů se serverové ovládací prvky HTML používají pro zpětnou kompatibilitu nebo tehdy, když je nutná rychlá migrace; v nových projektech se používají webové ovládací prvky.

Značky webových ovládacích prvků ASP.NET vždy začínají prefixem asp:, za kterým následuje název třídy.

Například následující fragment vytvoří textové pole a zaškrtávací políčko: <asp:TextBox id="myASPText" Text="Textové pole ASP.NET, nazdar!" runat="server" /> <asp:CheckBox id="myASPCheck" Text="Moje zaškrtávací políčko" runat="server" />

Opět si připomeňme, že s oběma ovládacími prvky je možné komunikovat s např. využitím tohoto kódu: myASPText.Text = "Nový text"; myASPCheck.Text = "Zaškrtni mně!";

Všimněte si, že vlastnost Value, se kterou jste se setkali u ovládacího prvku HTML, byla nahrazena vlastností Text. Vlastnost HtmlInputText.Value tak byla původně pojmenována proto, aby to souhlasilo s odpovídajícím atributem value u značky <input> v HTML. Webové ovládací prvky však nekladou takový důraz na vztahy k syntaxi HTML, takže byl zvolen lépe výstižnější název vlastnosti, tedy Text.

Rodina webových ovládacích prvků ASP.NET zahrnuje nejenom složitě se generující prvky (mezi ně patří Calendar a TreeView), ale také poměrně přímočaré prvky, jako textové pole, popisek nebo tlačítko (TextBox, Label, Button), které se poměrně úzce mapují na existující značky v HTML. V naposled zmíněném případu poskytují obě varianty, jak serverový ovládací prvek HTML, tak i webový ovládací prvek ASP.NET, obdobnou funkcionalitu, i když u webových ovládacích prvků je tendence vystavovat standardizovanější a bezproblémovější rozhraní. To znamená, že webové ovládací prvky se dají snadno zvládnout, nehledě na to, že to znamená, že na ně mohou plynule a zcela přirozeně přejít vývojáři Windows, kteří se přesídlují do světa webu, protože mnohé názvy vlastností jsou obdobné (v porovnání s odpovídajícími ovládacími prvky Windows).

Fakt 6: ASP.NET podporuje různá zařízení a různé prohlížeče Jednou z největších výzev, které čelí weboví vývojáři, je značná různorodost prohlížečů, které je potřeba podporovat. Všelijaké prohlížeče a jejich verze a jejich konfigurace se liší v tom, jak podporují HTML. Weboví vývojáři musejí zvolit, zda je potřeba obsah realizovat podle HTML 3.2, nebo podle HTML 4.0, nebo nějak

44

Kapitola 1 – Úvod do ASP.NET

úplně jinak, třeba podle XHTML 1.0, nebo dokonce podle WML (Wireless Markup Language), které je určeno pro mobilní zařízení. Tento problém, který vznik díky různým firmám vyrábějící prohlížeče, sužuje vývojáře už od chvíle, kdy World Wide Web Consortium schválilo první verzi HTML. A život se vám zkomplikuje ještě víc, pokud využívat nějaké rozšíření HTML, jako je JavaScript, abyste mohli vytvářet dynamičtější stránky nebo nabídnout možnost ověřit platnost vstupních dat.

ASP.NET se vypořádává s tímto problémem pozoruhodně inteligentně. Přestože můžete pomocí ASP.NET stránky získat informace o prohlížeči klienta a o jeho schopnostech, ASP.NET vybízí vývojáře, aby tyto věci ignorovali a využívali bohatě vybavenou skupinu webových ovládacích prvků. Ty realizují svůj kód HTML přizpůsobivě – berou totiž v úvahu schopnosti klienta. Jako vhodný příklad z ASP.NET zde mohou posloužit ovládací prvky pro ověřování platnosti vstupních dat (tzv. validátory), které pro rozšíření svých schopností používají JavaScript a DHTML (Dynamic HTML), za předpokladu, že je klient podporuje. To umožňuje těmto validačním ovládacím prvkům dynamicky zobrazovat chybové zprávy, aniž by uživatel musel stránku odesílat zpět na server k dalšímu zpracování. Jsou to sice schopnosti volitelné, ale dobře demonstrují, jak mohou inteligentní ovládací prvky vytěžit maximum z nejmodernějších prohlížečů, a přitom neponechat stranou ostatní klienty. A úplně nejlepší je to, že pro podporu obou druhů prohlížečů, jak těch moderních, tak i těch "méně moderních", nemusíte napsat ani řádek kódu navíc.

POZNÁMKA Bohužel – ASP.NET 2.0 stále ještě nestihlo do tohoto pěkného obrazu integrovat ovládací prvky pro mobilní zařízení. To znamená, že chcete-li vytvářet webové stránky pro různá chytrá zařízení (smart devices), jako jsou mobilní telefony nebo PDA, budete potřebovat sice podobný, nicméně oddělený toolkit. Tvůrci ASP.NET původně plánovali sjednocení obou modelů, aby bylo možné standardní sadu serverových ovládacích prvků vygenerovat pomocí jiných, méně obsáhlejších, standardů, jako třeba WML nebo HDML (Handheld Device Markup Language). Ovšem už brzy, ve fázi beta, byla tato schopnost ASP.NET 2.0 kompletně smetena ze stolu.

Fakt 7: ASP.NET se snadno rozmisťuje a konfiguruje Jednou z věcí, ze kterých vývojáře během vývojového cyklu nejvíce bolí hlava, je rozmístění dokončené aplikace do rutinního provozu na ostrý server. Nejenom, že je nutné přenést soubory webových stránek, databáze a komponenty, ale musí se také zaregistrovat komponenty a opětovně vytvořit hromadu konfiguračních nastavení. ASP.NET celý tento proces značně zjednodušuje.

Každá instalace .NET Frameworku poskytuje stejné jádro tříd. Z toho plyne, že se aplikace ASP.NET rozmisťují relativně snadno. Ve většině případů stačí pouze zkopírovat všechny soubory do nějakého virtuálního adresáře na ostrém serveru (pomocí nějakého FTP programu nebo pomocí příkazového řádku). Pokud má hostitelský stroj .NET Framework, nejsou potřeba žádné registrační kroky, které by mohly být časově velmi náročné.

Distribuce komponent, které využívá vaše aplikace, je stejně snadná. Když rozmisťujete svou aplikaci, není nutné udělat nic víc, než zkopírovat všechny komponenty. Protože jsou všechny informace o komponentě uloženy přímo v metadatech souboru assembly, není potřeba spouštět nějaký registrační program nebo modifikovat registr Windows. Pokud umístíte své komponenty na správné místo (do podadresáře Bin adresáře webové aplikace), bude je engine ASP.NET detekovat automaticky a učiní je dostupnými pro kód vaší webové stránky. Zkuste udělat to samé s klasickou komponentou COM! Konfigurace je další výzvou, se kterou je nutné se při rozmisťování aplikací vypořádat, zejména tehdy, když potřebujete přenášet informace týkající se bezpečnosti, jako jsou účty uživatelů či oprávnění přidělená uživatelům. ASP.NET tuto fázi rozmisťovacího procesu usnadňuje tím, že minimalizuje závislost na nastavení v IIS

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

45

(Internet Information Services). Většina nastavení ASP.NET se tak ukládá v souboru web.config, který existuje právě pro tento účel. Soubor web.config se umístí do téhož adresáře, kde máte své webové stránky. Obsahuje hierarchická seskupení nastavení aplikace, která jsou uložená ve formátu XML. Takový soubor se dá snadno přečíst a k jeho editaci nepotřebujete nic více, než pouhý textový editor, například Poznámkový blok. Když nějaké modifikujete nějaké nastavení aplikace, ASP.NET si toho všimne, a hladce restartuje aplikaci v nové doméně aplikace (doménu existující aplikace pak nechá v provozu tak dlouho, dokud se neukončí zpracování všech doposud nevyřešených požadavků). Soubor web.config není nikdy uzamčen, takže jej můžete aktualizovat skutečně kdykoliv.

ASP.NET 2.0 – příběh pokračuje Když Microsoft vydal ASP.NET 1.0, ani on přesně neodhadl, s jakým nadšením bude tato nová technologie přijata. ASP.NET se rychle stalo standardem pro vývoj webových aplikací s technologiemi Microsoftu a velmi zdatným konkurentem pro všechny ostatní platformy webového vývoje.

POZNÁMKA Statistiky o tom, jak to, či ono přijala veřejnost, jsou vždy problematické, ale vysoce uznávaná internetová analytická firma Netcraft (http://www.netcraft.com) došla k závěru, že používání ASP.NET roste každým rokem o dvojnásobek, a že nyní běží na více webových serverech než JSP. Její průzkum sice nezahrnoval relativními velikost zkoumaných webů, ale ASP.NET pohání významné množství webů firem uvedených v žebříčku časopisu Fortune.

Důkazem dobrého návrhu ASP.NET 1.0 a 1.1 je to, že pouze velmi málo změn v ASP.NET 2.0 jsou opravami existujících schopností. ASP.NET 2.0 si ponechává stejné osvědčené základy, a zaměřuje se na přidávání nových funkcionalit. Jinak řečeno – ASP.NET 2.0 obsahuje více nových schopností, různých parádiček a nástrojů, což zvyšuje produktivitu vývojáře. Cílem, jak prohlásil tým ASP.NET, je zredukovat počet řádků kódu, které musíte napsat, až o 70 procent.

POZNÁMKA Ve skutečném světě se v případě profesionálních webových aplikací určitě nedocílí sedmdesátiprocentní redukce kódu. Patrně však budete překvapeni, až naleznete nové schopnosti, které budete moci implementovat do svých aplikací s využitím velmi malého množství úprav. A na rozdíl od mnohých nedopečených parádiček si nebudete muset nechat zajít chuť na tyto věci, protože se vám nebude chtít začít budovat svou aplikaci znovu od samého začátku. Ne. Opravdu budete schopni zapojit své vlastní moduly přímo do existujícího pracovního rámce, takže konečným výsledkem bude úspora času, zdokonalená flexibilita a opětovná využitelnost.

Oficiálně je ASP.NET 2.0 zpětně kompatibilní s ASP.NET 1.0. V realitě ovšem stoprocentní zpětná kompatibilita nikdy neexistuje, protože opravy některých chyb a možných nekonzistencí v jazyku mohou změnit způsob práce již existujícího kódu. Microsoft udržuje seznam takových rušivých změn (většina z nich je velmi bezvýznamných) na http://www.gotdotnet.com/team/changeinfo/Backwards1.1to2.0. Je velmi nepravděpodobné, že byste se dostali do nějakých potíží, až budete přenášet nějaký projekt z ASP.NET 1.x do ASP.NET 2.0. Mnohem pravděpodobnější je, že narazíte na případy, kdy starý způsob řešení nějakého problému bude stále fungovat, nicméně ASP.NET 2.0 bude přinášet mnohem lepší přístup. Pak bude jenom na vás, zdali ponecháte stávající stav, nebo jestli se pokusíte svou webovou aplikaci upravit tak, aby mohla těžit z výhod plynoucích z nových schopností.

46

Kapitola 1 – Úvod do ASP.NET

Samozřejmě – ASP.NET 2.0 se neomezuje pouze na přidávání nových schopností. Přispívá také k vyššímu výkonu a zjednodušuje konfiguraci s novým nástrojem, který je pojmenován jako WAT (Website Administration Tool). V následujících částech se seznámíte s některými nejdůležitějšími změnami obsaženými v různých částech .NET Frameworku.

C# verze 2005 C# obsahuje ve verzi 2005 několik nových schopností. Některé z nich jsou dost exotické, a budou předmětem obdivu jen u opravdových příznivců tohoto jazyka, jiné jsou ale užitečné všeobecněji. Mezi nové schopnosti patří:

•

Parciální třídy (partial classes). Parciální třídy umožňují rozdělit třídu C# do dvou nebo více souborů zdrojového kódu. Tato schopnost je určena primárně k tomu, aby se skryly zapeklité detaily, které nemusí mít člověk pořád na očích. Visual Studio využívá parciální třídy v některých typech projektů – pro odklizení automaticky generovaného kódu z dohledu.

•

Generičnost (generics). Umožňuje vytvářet třídy, které jsou dostatečně flexibilní na to, aby uměly pracovat s různými typy tříd, a současně podporovaly kontrolu silného typování. Pomocí této schopnosti můžete například napsat kód pro třídu kolekce, do které se bude moci ukládat jakýkoliv typ objektu. Když pak vytvoříte instanci této kolekce, "uzamknete ji" na třídu, kterou jste si zvolili, takže se do ní budou moci ukládat pouze data jediného typu. Důležitým faktem uvedeného příkladu je to, že třídu uzamknete až v okamžiku jejího použití, nikoliv v okamžiku, kdy vytváříte její kód.

•

Anonymní metody. Anonymní metody umožňují definovat blok kódu "za pochodu", uvnitř jiné metody. Pomocí této techniky se dají rychle zavěšovat ovladače událostí (event handler).

•

Iterátory. Iterátory umožňují snadno vytvářet třídy, které podporují vypočítávání (enumeration), což znamená, že můžete projít v cyklu hodnoty, které obsahují, pomocí příkazu foreach.

Parciální třídy uvidíte v akci v kapitole 2, generické třídy s kolekcemi později. Anonymní metody a iterátory patří mezi speciality, a této v knize se nepopisují (o obou těchto schopnostech C# se však můžete dozvědět více v článku, který je na adrese http://www.ondotnet.com/pub/a/dotnet/2004/04/05/csharpwhidbeypt1.html).

Visual Studio 2005 Pro vytváření webových aplikací s ASP .NET 1.x společnost Microsoft poskytovala dva oddělené nástroje – plnohodnotné Visual Studio .NET a volně dostupný program Web Matrix. Profesionální vývojáři vesměs favorizují Visual Studio .NET, nicméně Web Matrix nabízel několik inovačních schopností navíc. Protože Web Matrix obsahoval svůj vlastní, ovšem poněkud "očesaný" webový server, mohli programátoři vytvářet a testovat webové aplikace, aniž by se museli na svém počítači starat o konfiguraci virtuálních adresářů s využitím IIS. Pro .NET 2.0 už není Web Matrix dostupný, nicméně Visual Studio získalo některé z jeho nejlepších schopností, včetně integrovaného webového serveru, což umožňuje okamžitě, bez předběžných příprav, začít pracovat s testovacím webem.

Další vítanou změnou ve Visual Studiu 2005 je podpora různých způsobů programování. Zatímco Visual Studio .NET 2003 nabízelo pouze jeden způsob, Visual Studio 2005 podporuje různé způsoby programování, takže je to opravdu flexibilní a všestranně využitelný designérský nástroj. Můžete si například zvolit, zdali HTML značky a kód pro zpracování událostí dáte do jediného nebo do více souborů, aniž byste přitom narušili možnost plně využívat Visual Studio a těžit z jeho dodatečných schopností, jakou je třeba IntelliSense.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

47

(O právě popsaném rozdílu se dozvíte více v kapitole 2.) V jednom projektu můžete rovněž používat více než jeden programovací jazyk. Můžete tak například směšovat webové stránky obsahující kód C# s webovými stránkami s Visual Basicem atd.

ASP.NET 2.0 V této knize většinou nerozlišujeme mezi schopnostmi, které jsou nové v ASP.NET 2.0, a mezi těmi, které už existují od ASP.NET 1.0. Hlavní rozdíly však uvádíme v několika následujících částech.

Vzory stránek Potřebujete implementovat jednotný vzhled na více stránkách? Se vzory stránek (master pages) můžete nadefinovat šablonu, a bez dalšího úsilí ji opětovně využívat. Například pomocí šablony můžete zajistit, aby měla každá webová stránka v aplikaci stejné záhlaví, stejné zápatí a obsahovala stejné navigační ovládací prvky.

Ve vzorech stránek se definují konkrétní regiony, které je možné editovat; říká se jim obsahové regiony (content regions). Každá stránka, která používá nějaký vzor stránek, získává zcela automaticky svůj layout a své pevné prvky a dodává obsah pro tyto regiony.

Na obrázku 1-3 vidíte ukázku webové stránky s obsahovým regionem v režimu designu Visual Studia. Vzorová stránka, resp. šablona stránky, dodá záhlaví a formátování stránky. Obsahová stránka (content page) pak vloží do konkrétního regionu dodatečný kód HTML a webové ovládací prvky.

Obrázek 1-3. Webová stránka s regionem pro obsah v režimu designu.

V souvislosti se vzory stránek zde musím připomenout, že ASP.NET obsahuje také novou schopnost, která se nazývá jako motivy (themes). Motivy umožňují nadefinovat standardizovanou sadu charakteristik vzhledu webových ovládacích prvků. Jakmile nadefinujete tyto formátovací předvolby, můžete je použít pro celý svůj web, takže všechny webové stránky budou mít jednotný vzhled.

Je poměrně zajímavé, že jak vzor stránek, tak i motiv můžete nastavovat při běhu aplikace. To znamená, že můžete napsat kód, jehož prostřednictvím můžete používat různé motivy a různé vzory podle toho, o jakého uživatele se jedná, nebo podle toho, jaké jsou jeho preference. Vzory stránek a motivy lze proto využívat

48

Kapitola 1 – Úvod do ASP.NET

nejenom pro standardizaci celkového vzhledu webu, ale také pro přizpůsobení vzhledu webu jednotlivým uživatelům. Vzory stránek a motivy se podrobněji probírají v kapitole 15.

Ovládací prvky pro zdroje dat Už jste unaveni z neustálého načítání, formátování a zobrazování svých dat? S novým modelem ovládacích prvků pro zdroje dat můžete ve stránce deklarativně definovat, jak má stránka komunikovat se zdrojem dat.

Nemusíte tak opakovaně vytvářet stejný kód pro přístup k datovým objektům. Nejlepší ale na tom je, že vás tahle schopnost nijak nenutí, abyste se vzdali dobrého návrhu založeného na komponentách – vlastní datovou komponentu můžete využít právě tak snadno, jako když se vážete přímo na databázi.

Podívejte se, jak funguje nový model vázání dat v té nejjednodušší situaci. Nejprve ve Visual Studiu přetáhněte a upusťte na stránku ovládací prvek GridView, nebo jej napište ručně tímto způsobem: <asp:GridView id="MyDataGrid" runat="server"/>

Poté je potřeba přidat zdroj dat, který načte řádky z databáze, o které máte zájem, a který je učiní dostupnými pro GridView. V našem jednoduchém příkladu se pomocí SqlDataSource napojíme přímo na databázi SQL serveru. V profesionální aplikaci se obvykle používá ObjectDataSource, aby se prošlo skrze oddělenou vrstvu vlastních komponent. Pro vytvoření značky SqlDataSource potřebujeme znát několik detailů, jako např. dotaz, pomocí kterého se získají požadované záznamy z databáze, a připojovací řetězec, který se použije pro připojení k databázi. Celý proces můžete absolvovat buď v průvodci Visual Studia, nebo napsat celý kód ručně.

Ať už to uděláte jakkoliv, nakonec skončíte s něčím takovým, jako je tohle (za předpokladu, že databáze SQL serveru, ke které se chcete připojit, je na aktuálním počítači a podporuje autentizaci Windows): <asp:SqlDataSource ID="CustomersList" Runat="server" SelectCommand="SELECT CompanyName, ContactName, ContactTitle, City FROM Customers" ConnectionString= "Data Source=127.0.0.1;Integrated Security=SSPI;Initial Catalog=Northwind"> </asp:SqlDataSource>

Uvedený zdroj dat definuje jak připojení k databázi pojmenované jako Northwind, tak i operaci specifikovanou dotazem SELECT, který načte všechny záznamy z tabulky Customers.

A nakonec je potřeba svázat tento zdroj dat s GridView. Uděláme to tak, že nastavíme vlastnost DataSourceID objektu GridView na název SqlDataSource (v našem případě je to CustomersList). To se dá udělat ručně, nebo v okně Properties. Každopádně skončíte se značkou GridView v této podobě: <asp:GridView id="MyDataGrid" DataSourceID="CustomersList" runat="server"/>

Aniž byste museli psát nějaký další kód nebo přidávat k ovládacímu prvku GridView nějaké speciální formátování (a že existuje spousta nastavení právě pro tohle), získáte ničím nepřikrášlovanou tabulku z obrázku 1-4. Tento základní vzhled tabulky pak můžete dále vylepšovat – např. definovat hodnoty pro styl písma, barvu pozadí, styl záhlaví a mnoho dalších věcí. Můžete také zapnout schopnosti pro řazení podle zvoleného sloupce, stránkování (tabulka se rozčlení do několika stránek), výběr či editování.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

49

Obrázek 1-4. Jednoduchá tabulka zobrazující získaná data.

Kromě GridView ASP.NET 2.0 dále nabízí nové ovládací prvky pro zobrazování dat, mezi které patří DetailsView a FormView. Oba mohou fungovat i jako prohlížeč záznamů – mohou v daném okamžiku zobrazovat podrobné informace pouze o jediném záznamu. Také podporují editaci. Novým schopnostem práce s daty se podstatně více věnuje druhá část knihy.

Personalizace Většina webových aplikací pracuje s daty, která jsou specifická pro daného uživatele. Pokud například vytváříte web internetového obchodu, bude asi potřeba, abyste ukládali a podle potřeby načítali poštovní adresu aktuálního uživatele, jeho preference ohledně prohlíženého obsahu webu, obsah nákupního košíku atd.

ASP.NET 1.x umožňovalo na krátkou dobu ukládat tyto informace do stavu relace (session state). Rozhodnutí, zdali tyto informace ukládat do nějaké databáze pro případné budoucí využití, pak bylo pouze na vás.

ASP.NET 2.0 se s tímto omezením vypořádává pomocí personalizace, což je API určené pro zacházení s informacemi specifickými pro jednotlivé uživatele, které jsou uložené v databázi. Myšlenka personalizace je založena na tom, že ASP.NET vytvoří objekt profilu, v němž pak můžete kdykoliv přistupovat k informacím specifickým pro daného uživatele. ASP.NET se pak v zákulisí postará o tu nudnou práci spojenou s načítáním dat profilu v okamžiku, kdy jsou zapotřebí, a také s uložením dat profilu při jejich aktualizaci.

Většina seriózních vývojářů rychle zjistí, že výchozí implementace personalizace, která je určena pro všechny možné případy, nevyhovuje jejich konkrétním potřebám. Třeba v případě, když potřebujete používat existující databázové tabulky, ukládat zašifrované informace, nebo přizpůsobit styl ukládání objemově velkých dat do cache, protože potřebujete zvýšit výkon? Zajímavé je, že personalizaci si můžete přizpůsobit, aby lépe vyhovovala vašim potřebám tím, že si vytvoříte vlastního poskytovatele personalizace. Pak budete moci lépe využívat pohodlí personalizačních schopností, a současně mít kontrolu nad nízkoúrovňovými detaily. Nevýhodou takového postupu je to, že něco z toho budete muset naprogramovat sami (zapomeňte na slibovanou redukci kódu o 70 procent). Získáte však větší flexibilitu a jednotný model profilů. Personalizace se podrobněji probírá v kapitole 24.

50

Kapitola 1 – Úvod do ASP.NET

TIP Mnoho ze schopností ASP.NET 2.0 pracuje prostřednictvím abstrakce, která se nazývá jako model poskytovatele (provider model). Elegance modelu poskytovatele spočívá v tom, že při budování kódu stránek můžete používat jednoduché poskytovatele. Jestliže se vaše požadavky změní, nebudete muset měnit ani jedinou stránku – místo toho postačí, když si vytvoříte vlastního poskytovatele. Model poskytovatele je natolik užitečný, že podobný vzor uspořádání byl použit pro obdobná, ručně vyrobená, řešení v prvním vydání této knihy (ještě předtím, než se na scéně objevilo ASP.NET 2.0).

Bezpečnost a členství Jednou z nejužitečnějších schopností v ASP.NET 1.x byla formulářová autentizace, což byl systém založený na cookies, který byl určený pro sledování uživatelů, kteří prokázali svou totožnost. Přestože formulářová autentizace fungovala perfektně, jednalo-li se o bezpečnost webu, bylo na vývojáři, aby sám napsal kód, na jehož základě uživatelé prokazovali svou totožnost na přihlašovací stránce. Formulářová autentizace navíc neposkytovala žádnou funkcionalitu pro autorizaci uživatele (tedy možnost zkontrolovat, zdali má aktuální uživatel přiřazenou nějakou sadu oprávnění), což znamenalo, že pokud vývojáři tyto funkcionality potřebovali, museli si je vytvořit úplně sami od začátku.

ASP.NET 2.0 se vypořádává s oběma těmito nedostatky tím, že rozšiřuje formulářovou autentizaci o nové schopnosti. ASP.NET předně obsahuje automatickou podporu sledování přihlašovacích dokladů uživatele (credentials), bezpečným způsobem ukládá hesla, a provádí autentizaci uživatelů na přihlašovací stránce.

Tuto funkcionalitu si můžete přizpůsobit podle vašich existujících databázových tabulek, nebo můžete jednoduše ASP.NET sdělit, kde máte umístěný databázový server, a nechat vše na něm. A kromě toho, ASP.NET obsahuje i několik nových ovládacích prvků určených pro správu bezpečnosti, které umožňují uživatelům provést novou registraci, přihlášení nebo získat zapomenuté heslo. Ovládací prvky můžete nechat, ať pracují po svém, nebo je můžete nakonfigurovat tak, aby zcela vyhovovaly vašim specifickým požadavkům.

A konečně – ASP.NET přidává podporu pro autorizaci pomocí API pro členství (membership API). Členství umožňuje používat autorizaci založenou na rolích. Své uživatele zařadíte do různých skupin (jako Host, Administrátor, či Prodejce), a předtím, než uživateli povolíte nějakou konkrétní akci, otestujete, zdali je členem skupiny oprávněné provádět danou akci. Nejlepší na tom je, že členství je zapojeno přímo do bezpečnostní infrastruktury založené na formulářích. Více se dozvíte ve čtvrté části knihy.

Bohatě vybavené ovládací prvky Věřte nebo ne, ASP.NET představuje více než 40 nových ovládacích prvků. Mnohé z nich podporují nové funkcionality, jako jsou prvky zasvěcené bezpečnosti, nebo ovládací prvky webových částí (web parts), které jsou určeny pro portály. Také zjistíte, že je po ruce šikovný průvodce a ovládací prvek MultiView, takže můžete vytvářet stránky s několika různými zobrazeními. Ale pravděpodobně nejvíce užitečným novým ovládacím prvkem je nový TreeView a prvek Menu založený na JavaScriptu.

TreeView umožňuje používat hierarchické (stromové) zobrazení dat se značnými možnostmi pro přizpůsobení. Několik variant TreeView s různým grafickým ztvárněním uzlů je možné vidět na obrázku 1-5.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

51

Obrázek 1-5. Několik variant prvku TreeView.

Nový ovládací prvek Menu rovněž slouží k zobrazování hierarchické struktury dat, ale je založen na JavaScriptu. Když hýbete kurzorem myši, objevují se dynamicky příslušné podnabídky, které se zobrazují na aktuální webové stránce (viz obrázek 1-6).

Obrázek 1-6. Dynamický ovládací prvek Menu.

52

Kapitola 1 – Úvod do ASP.NET

TreeView i Menu se dají využít nejenom pro prezentaci jakýchkoliv dat, ale i pro zobrazení navigačního stromu, takže uživatelé mohou na vašem webu pohodlně přecházet z jedné stránky na jinou. A aby byla navigace ještě snadnější, ASP.NET přidává volitelný model pro vytvoření mapy webu (site map). Jakmile vytvoříte nějakou mapu webu, můžete ji bezproblémově využít v navigaci. Nejlepší na to je, že od tohoto okamžiku můžete měnit strukturu webu, přidávat nové stránky, aniž byste byli nuceni modifikovat cokoliv jiného, než jediný soubor s mapou webu. Navigační ovládací prvky uvidíte v akci v kapitole 16.

Webové části Jednou z běžných webových aplikací je portál, který zobrazuje na jediné webové stránce různé informace pomocí oddělených panelů. Přestože bylo možné web ve stylu portálu vytvářet už v ASP.NET 1.x, museli jste to dělat ručně. V ASP.NET 2.0 je k dispozici nová schopnost nazvaná jako webové části (web parts), která dramaticky ulehčuje život vývojáře pomocí předem vytvořeného pracovního rámce pro portál. A tato schopnost je opravdu užitečná – nabízí plovoucí layout webu, velké množství konfigurovatelných zobrazení či podporu funkcionality "táhni a pusť" (drag-and-drop). Pokud se chystáte na vytvoření nějakého webového portálu s těmito schopnostmi, můžeme v tomto případě říci, že ASP.NET 2.0 splní svůj slib ohledně oněch slibovaných 70 procent úspor v kódu. Více se o této užitečné schopnosti dozvíte v kapitole 31.

Administrace Pokud jste chtěli v ASP.NET 1.x změnit nastavení nějaké aplikace, bylo potřeba ručně editovat příslušný konfigurační soubor. I když to nebyl nijak obtížný úkol, ASP.NET 2.0 ho usnadňuje pomocí webového administračního nástroje, který existuje pouze pro tento účel, a který funguje prostřednictvím webového rozhraní.

Nástroj se jmenuje WAT, a je užitečný zejména tehdy, když využíváte schopnosti pro personalizaci a členství.

Je to z toho důvodu, že WAT poskytuje pohodlné (i když poněkud zdlouhavé) rozhraní, v němž se dají nadefinovat data specifická pro konkrétního uživatele, přidávat nové uživatele, přiřazovat uživatele k rolím a mnoho dalších věcí. Na WAT se blíže podíváme v kapitole 5.

Shrnutí Doposud jen kloužeme po povrchu schopností a parádiček, které poskytuje ASP.NET a .NET Framework.

V této kapitole jste se zběžně seznámili s hlavními pojmy, které musíte pochopit, chcete-li se stát kompetentními programátory v ASP.NET. Také jste získali úvodní představu o nových schopnostech, které nabízí ASP. NET 2.0. O jednotlivých inovacích a dalších revolučních změnách v ASP.NET 2.0 a .NET Frameworku se postupně dozvíte v dalších kapitolách knihy.

KAPITOLA 5 Aplikace ASP.NET V tradičním desktopovém programování se aplikací rozumí spustitelný soubor a podpůrné soubory, které se k němu vztahují. Například typická aplikace Windows se skládá z hlavního spustitelného souboru (EXE), podpůrných komponent (typicky DLL) a dalších zdrojů, jakou jsou databáze a konfigurační soubory. Aplikace ASP.NET používají dost odlišný model.

Na té nejzákladnější úrovni je aplikace ASP.NET kombinací souborů, stránek, ovladačů (handlers), modulů a spustitelného kódu, který se dá vyvolat z nějakého virtuálního adresáře (a z jeho podadresářů) na nějakém webovém serveru. V této kapitole se dozvíte, proč taková odlišnost existuje, a podíváte se poněkud blíže na to, jak se aplikace ASP.NET konfiguruje a rozmisťuje. Také se dozvíte, jak se s aplikací ASP.NET používají komponenty a ovladače HTTP.

ZMĚNY VE WEBOVÉ APLIKACI V .NET 2.0 Model webové aplikace zůstal v ASP.NET 2.0 v podstatě stejný. Nejvýznamnější změnou je zdokonalení konfiguračního modelu, který se nyní honosí programovatelným API a grafickým rozhraním webové stránky.

Změny, s nimiž se seznámíte, jsou uvedeny v následujícím výčtu. Uvádíme je v pořadí, v jakém se v kapitole probírají:

•

Struktura adresářů aplikace. ASP.NET 1.x měl jeden speciální adresář webové aplikace – adresář Bin, ve kterém sídlily zkompilované assembly. ASP.NET 2.0 jich přidává několik navíc: pro zdrojový kód, lokalizovatelné zdroje, definice prohlížeče, motivy a další.

•

Konfigurační API. Nyní můžete pomocí šikovné sady tříd číst a zapisovat téměř jakékoliv informace konfiguračního souboru.

•

WAT. Nový nástroj pro administraci webu (Website Administration Tool) prezentuje pomocí nového konfiguračního API snadno zvládnutelné rozhraní v podobě webové stránky, v němž se dá nakonfigurovat webová aplikace.

•

Sekce konfigurace lze zašifrovat. Konfigurační soubory často obsahují citlivá data. Nyní je můžete ochránit tím, že jakoukoliv sekci je možné zašifrovat.

Jste-li příležitostným vývojářem ASP.NET 1.x, můžete číst tuto kapitolu tak, že se soustředíte hlavně na právě zmíněné novinky.

194

Kapitola 5 – Aplikace ASP.NET

Anatomie aplikace ASP.NET Rozdíl mezi aplikací ASP.NET a bohatě vybavenou klientskou aplikací se vám hodně objasní, když se podíváme na model vykonávání aplikace ASP.NET. Na rozdíl od aplikace Windows, konečný uživatel nikdy přímo nespouští aplikaci ASP.NET. Uživatel spustí nějaký prohlížeč, například Internet Explorer, a požaduje přes HTTP nějakou konkrétní URL (jako je http://www.mujweb.com/mojestranka.aspx). Požadavek dorazí na nějaký webový server. Když aplikaci ladíte ve Visual Studiu, používáte výhradně místní testovací server. Když aplikaci rozmístíte, používáte webový server IIS, což se popisuje v kapitole 18.

Webový server nezná žádný pojem separátní aplikace – předá prostě požadavek zpracovatelskému procesu (worker process) ASP.NET. Zpracovatelský proces ASP.NET však pečlivě odděluje vykonávání kódu do domén aplikace založených na virtuálním adresáři. Webové stránky a webové služby, jejichž hostitelem je týž virtuální adresář (nebo některý z jeho podadresářů) se vykonávají v téže doméně. Webové stránky a webové služby, které jsou v různých virtuálních adresářích, se vykonávají v separátních doménách.

POZNÁMKA Virtuální adresář je prostě adresář, který je vystavený prostřednictvím nějakého webového serveru. To, jak se vytvářejí virtuální adresáře, se dozvíte v kapitole 18. Používáte-li testovací server Visual Studia, s adresářem webového projektu se zachází jako s virtuálním adresářem. Jedinou výjimkou je, že testovací server výhradně podporuje místní připojení (tedy požadavky iniciované z aktuálního počítače).

Doména aplikace Doména aplikace je ekvivalent .NET pro proces – je to jistá hranice vynucená CLR, která zajišťuje, že jedna aplikace nemůže ovlivnit jinou aplikaci (nebo vidět její data nacházející se v paměti). Přímé důsledky modelu domény aplikace jsou následující:

•

Všechny webové stránky a webové služby v jedné webové aplikaci sdílejí stejné paměťové zdroje, jako jsou globální data aplikace, data relace jednotlivých uživatelů a data uložená do cache. Tyto informace nejsou přímo dostupné jiným ASP.NET nebo ASP aplikacím.

•

Všechny webové stránky a webové služby v jedné webové aplikaci sdílejí stejné jádro konfiguračních nastavení. Některá konfigurační nastavení však můžete přizpůsobovat v jednotlivých podadresářích téhož virtuálního adresáře. Například pro webovou aplikaci můžete nastavit pouze jediný mechanismus autentizace (ověřování totožnosti uživatelů), bez ohledu na to, kolik podadresářů má. Můžete ovšem v každém adresáři nastavit jiná pravidla autorizace, abyste mohli lépe specifikovat, kdo má mít přístup těm či oněm skupinám stránek a kdo ne.

•

Všechny webové aplikace vyvolávají v různých etapách globální události aplikace (když se úplně poprvé vytvoří doména aplikace, když se zničí atd.), k nimž můžete připojovat ovladače událostí. Ty budou na události aplikace reagovat pomocí kódu uvedeného v globálním souboru .asax, který bude uložen ve virtuálním adresáři aplikace.

Jinak řečeno – virtuální adresář je základní seskupující struktura, která odděluje aplikaci ASP.NET. Legitimní ASP.NET aplikace může mít klidně pouze jedinou webovou stránku (soubor .aspx), nebo webovou službu (soubor .asmx). Obecně však může aplikace ASP.NET obsahovat všechny následující ingredience:

• •

Webové stránky (soubory .aspx). Základní stavební bloky jakékoliv aplikace ASP.NET. Webové služby (soubory .asmx). Umožňují sdílet užitečné funkce s aplikacemi na jiných počítačích a jiných platformách.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

195

•

Soubory kódu v pozadí (code-behind files). V závislosti na tom, jaký model kódu používáte, můžete také mít oddělené soubory se zdrojovým kódem. Jsou-li napsány v jazyku C#, budou mít příponu .cs.

•

Konfigurační soubor (web.config). Obsahuje spoustu nastavení na úrovně aplikace. Pomocí těchto nastavení se konfiguruje všechno možné – např. věci týkající se bezpečnosti, ladění, či správy stavu (state management).

•

Global.asax. Obsahuje ovladače událostí, jež reagují na globální události aplikace (jako třeba událost, když aplikace startuje úplně poprvé).

•

Další komponenty. Jedná se o zkompilované assembly obsahující separátní komponenty, které jste vyvinuli sami, nebo se jedná komponenty s užitečnou funkcionalitou od jiných výrobců. Komponenty umožňují oddělovat obchodní logiku od logiky přístupu k datům a vytvářet vlastní ovládací prvky.

Virtuální adresář může dále obsahovat značné množství dalších zdrojů, které bude webová aplikace ASP. NET používat. Patří mezi ně stylové předpisy (stylesheets), obrázky, soubory XML atd. Kromě toho se dá model ASP.NET rozšiřovat tím, že vyvinete specializované komponenty známé jako ovladače HTTP a moduly HTTP, které se mohou zapojit do vaší aplikace a participovat na zpracování webových požadavků ASP.NET. POZNÁMKA V jednom virtuálním adresáři je možné mít i typy souborů, které vlastní odlišná rozšíření ISAPI. Může se například stát, že tam budete mít směsici souborů .aspx a .asp. Složitějším příkladem je to, pokud mapujete soubory .aspx webových stránek na verzi 1.1 ASP.NET a soubory .asmx webových služeb na verzi 2.0.

V těchto situacích bude jeden virtuální adresář odpovídat více než jedné aplikaci. Aplikace pak jsou přístupné prostřednictvím jediného virtuálního webového adresáře. Každou aplikaci však bude zprostředkovávat jiné rozšíření ISAPI.

Doba života aplikace ASP.NET používá techniku tzv. lenivé inicializace (lazy initialization) při vytváření domén aplikace. Tím je řečeno to, že doména aplikace pro webovou aplikaci vytvoří až tehdy, když úplně poprvé dorazí požadavek na nějakou stránku nebo službu z této aplikace.

Doména aplikace může být "shozena" z nejrůznějších příčin, včetně té, že byl "shozen" samotný webový server. Běžněji se ale aplikace samy restartují v nových doménách aplikace kvůli tomu, že reagují na nějakou chybovou podmínku nebo na nějakou změnu v konfiguraci. Například podle toho, jaká jsou nastavení v konfiguračním souboru machine.config (tedy na úrovni stroje), může být aplikace ASP.NET pravidelně recyklována, když se narazí na jisté limity. Tento model byl navržen proto, aby byly aplikace stále v dobrém zdravotním stavu, a aby se daly detekovat takové charakteristiky, které mohou indikovat vznik nějakých potíží. V závislosti na tom, jaká máte v souboru machine.config nastavení, se mohou domény aplikace recyklovat podle toho, jak dlouho se provozují, podle počtu požadavků ve frontě, nebo podle množství používané paměti (více to popisujeme v kapitole 18).

Když změníte aplikaci, ASP.NET automaticky recykluje její domény aplikace. Například jste nějak modifikovali soubor web.config. Jiným příkladem může být to, že nahradíte nějaký existující soubor webové stránky nebo DLL soubor assembly nějakým jiným souborem. V obou případech ASP.NET vytvoří novou doménu aplikace pro potřeby zpracování všech budoucích požadavků, přičemž zachová existující doménu aplikace

196

Kapitola 5 – Aplikace ASP.NET

na tak dlouho, dokud se nedokončí zpracování všech dosud nevyřízených požadavků (včetně požadavků zařazených do fronty).

TIP Doménu webové aplikace je možné programátorským způsobem ukončit pomocí statické metody HttpRuntime.UnloadAppDomain(). (Aplikace se pak automaticky nastartuje při příštím požadavku.) Tato technika se sice používá pouze výjimečně, nicméně se může hodit, pokud na tomtéž serveru hostujete značný počet webových aplikací, ze kterých se některé aplikace používají pouze ojediněle. V takovém případě může být zátěž spočívající v tom, že stále udržujete všechny domény aplikace v provozu, příliš velká, takže se vyplatí, když málo frekventované domény aplikace ukončíte, abyste zvýšili rychlost obsluhy následujících požadavků.

Aktualizace aplikací Jednou z nejpozoruhodnějších schopností modelu vykonávání ASP.NET je to, že můžete webovou aplikaci aktualizovat (update), aniž byste museli restartovat webový server, nebo se starat o to, zdali tím nějak neuškodíte již existujícím klientům. To znamená, že ve virtuálním adresáři můžete přidávat, nahrazovat nebo odstraňovat soubory kdykoliv, kdy to potřebujete. ASP.NET pak přejde k nové doméně aplikace stejným způsobem, jako když modifikujete její konfigurační soubor web.config.

Mít možnost kdykoliv aktualizovat jakoukoliv část aplikace, aniž by se tím přerušily existující požadavky, je velmi mocná schopnost. Je však důležité, abyste porozuměli architektuře, která to umožňuje. Mnozí vývojáři dělají tu chybu, když předpokládají, že je to schopnost CLR, která umožňuje, aby ASP.NET mohlo hladce přejít k nové doméně aplikace. Realitou je ale, že CLR vždy uzamyká soubory assembly při jejich vykonávání.

Aby se ASP.NET s touto situací vypořádalo, ve skutečnosti nepoužívá soubory z virtuálního adresáře. Během procesu kompilace používá jinou techniku, která se nazývá jako stínová kopie (shadow copy). S její pomocí si ASP.NET vytvoří kopie vašich souborů, které jsou umístěny v adresáři c:\[WinDir]\Microsoft.NET\[Verze]\Temporary ASP.NET Files. Zpracovatelský proces ASP.NET pak assembly načítá z tohoto adresáře, což znamená, že uzamčené jsou tyto assembly.

Druhou částí příběhu je to, že ASP.NET je schopno detekovat změnu originálních souborů. Tento detail je dosti přímočarý – spoléhá se při něm na schopnost operačního systému Windows sledovat adresáře a soubory a okamžitě odesílat informace o změnách. ASP.NET si udržuje aktivní seznam všech assembly načtených uvnitř konkrétní domény aplikace, a pomocí monitorovacího kódu dává pozor na změny, na které se následně reaguje.

POZNÁMKA ASP.NET může používat soubory uložené v GAC, což je úschovna na úrovni počítače pro komponenty, které obsahují věci pro běžnou denní potřebu, jako jsou assembly pro celou knihovnu tříd .NET Frameworku. Do GAC můžete dávat i své vlastní assembly, ale webové aplikace se obvykle budou snadněji rozmisťovat a udržovat, když je tam dávat nebudete.

Struktura adresáře aplikace Každá webová aplikace by měla mít dobře a pečlivě naplánovanou strukturu adresářů. Nezávisle na tom, jako strukturu adresáře si navrhnete vy sami, ASP.NET specifikuje několik adresářů, které mají speciální význam.

ASP.NET 1.x používálo pouze jediný takový adresář – adresář Bin. ASP.NET 2.0 kromě něj používá několik dalších, ty jsou popsány v tabulce 5-1.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

197

Tabulka 5-1. Speciální adresáře ASP.NET. Adresář

Popis

Bin

Obsahuje všechny předem zkomplikované assembly .NET (obvykle DLL), které používá webová aplikace ASP.NET. Do těchto assembly patří předem zkompilované třídy webových stránek a webových služeb, a také jiné assembly, na které se tyto třídy odkazují.

App_Code

Obsahuje soubory zdrojového kódu, které se pro potřeby vaší aplikace dynamicky kompilují. Tyto soubory kódu jsou obvykle separátní komponenty, jako například nějaká přihlašovací komponenta nebo nějaká knihovna pro přístup k datům.

Zkompilovaný kód se nikdy neobjeví v adresáři Bin, protože jej ASP.NET umisťuje do dočasných adresářů, které používá pro dynamickou kompilaci.

App_GlobalResources

Do tohoto adresáře se ukládají globální zdroje, k nimž mají přístup všechny stránky webové aplikace. O zdrojích a lokalizacích se více dozvíte v kapitole 17.

App_LocalResources

Slouží stejnému účelu jako App_GlobalResources, s tím rozdílem, že zdroje budou dostupné pouze té stránce, pro kterou jsou určeny. O zdrojích a lokalizacích se více dozvíte v kapitole 17.

App_WebReferences

Do tohoto adresáře se ukládají odkazy na webové služby, které webová aplikace používá. Patří sem i soubory WSDL a dokumenty DISCO. Webové služby se probírají v šesté části knihy.

App_Data

Adresář vyhrazený pro úložiště dat, včetně databázových souborů SQL serveru 2005 Express a souborů XML. Soubory s daty si pochopitelně můžete ukládat i do jiných adresářů.

App_Browsers

Obsahuje definice prohlížečů uložené v XML souborech. Tyto soubory XML definují schopnosti webových prohlížečů pro různé akce. Přestože to ASP.NET dělá globálně (vzhledem k celému počítači), adresář App_Browsers umožňuje nakonfigurovat toto chování pro různé webové aplikace. Další informace o tom, jak ASP. NET rozlišuje jednotlivé prohlížeče, jsou uvedeny v kapitole 27.

App_Themes

Do tohot adresáře se ukládají motivy, které používá webová aplikace. Motivy se probírají v kapitole 15.

Soubor aplikace global.asax Soubor global.asax umožňuje vytvářet ovladače událostí, kteří reagují na globální události. Uživatelé nikdy nežádají o soubor global.asax přímo. Děje se to jinak. Soubor global.asax vykonává svůj kód automaticky (jako reakci na jisté události aplikace). Soubor global.asax poskytuje podobnou službu, jakou poskytoval soubor global.asa v klasických aplikacích ASP. Kód se do souboru global.asax píše podobně, jako když píšete kód do nějakého webového formuláře. Rozdíl je v tom, že global.asax neobsahuje žádné značky HTML nebo ASP.NET. Obsahuje metody s konkrétními předdefinovanými názvy. Například následující soubor global.asax reaguje na událost Application.EndRequest, ke které dojde těsně předtím, než se stránka odešle uživateli: <script language="C#" runat="server">

198

Kapitola 5 – Aplikace ASP.NET

protected void Application_OnEndRequest() { Response.Write("<hr />Tato stránka byla obsloužena v " + DateTime.Now.ToString()); } </script>

Přestože to není v souboru global.asax vyjádřeno, každý soubor global.asax definuje metody pro jedinou třídu – třídu aplikace. Třída Application je odvozená z HttpApplication, což znamená, že kód má přístup ke všem jejím veřejným a chráněným členům. V uvedené ukázce se používá objekt Response, který je poskytován jako zabudovaná vlastnost třídy HttpApplication.

Ovladač události v ukázce zapíše zápatí stránky, v němž uvede datum a čas, kdy byla stránka vytvořena. Protože reaguje na událost Application.EndRequest, vykoná se pokaždé, když se stránka požaduje, poté, co se dokončí zpracování veškerého kódu zpracovávajícího události v této stránce.

Stejně jako u webových formulářů, i zde můžete rozdělit obsah souboru global.asax do dvou souborů. V jednom bude deklarace souboru, druhý bude obsahovat kód. Protože však pro soubory global.asax není k dispozici žádný designérský povrch (design surface), toto rozdělení se nevyžaduje. Visual Studio vám nenabídne volbu vytvořit soubor global.asax s oddělenou třídou kódu v pozadí.

Soubor global.asax file sice není povinný, ale webová aplikace nesmí mít více než jeden soubor global.asax, který musí sídlit v kořenovém adresáři aplikace, nikoliv v nějakém podadresáři. Chcete-li do projektu přidat soubor global.asax, vyberte Website > Add New Item, a zvolte šablonu Global Application Class.

Když Visual Studio přidává soubor global.asax, vloží do něj prázdné ovladače nejčastěji používaných událostí aplikace. Vy pak pouze přidáte do patřičných metod kód, který má vykonávat.

Stojí za zmínku, že ovladače událostí aplikace se nepřiřazují stejným způsobem jako běžné ovladače událostí ovládacích prvků. Obvyklý způsob, jakým se rozpoznává ovladač události aplikace, je ten, že se použije dohodnutý název metody. Vytvoříte-li například chráněnou metodu s názvem Application_OnEndRequest(), ASP.NET ji bude volat automaticky, jakmile dojde k události Application.EndRequest.

ASP.NET vytváří fond objektů aplikace v okamžiku, když se poprvé načte doména vaší aplikace, přičemž jeden z objektů aplikace pak použije k obsluze požadavků. Velikost fondu závisí na systému a počtu dostupných vláken, obvykle ale bývá v rozsahu od 1 do 100 instancí. Každý požadavek získá výhradní přístup k jednomu z těchto objektů aplikace. Když daný požadavek skončí, bude objekt opětovně využit. V průběhu různých etap zpracování aplikace ASP.NET volá odpovídající metody, které pak spustí váš kód. Samozřejmě, má-li metoda špatný název, vaše implementace nebude zavolána – kód se bude prostě ignorovat.

POZNÁMKA Globální třída aplikace, kterou používá soubor global.asax, by měla být vždy bezstavová (stateless). To z toho důvodu, protože jakmile se objekty aplikace stanou dostupnými, opětovně se používají pro různé požadavky. Nastavíte-li v jednom požadavku hodnotu nějaké členské proměnné, mohla by se objevit i v jiném požadavku. Neexistuje však žádný způsob, jak specifikovat, jak se to má stát, nebo který z požadavků má získat tu či onu instanci objektu aplikace. Abyste se vyhnuli případným zádrhelům, nepoužívejte členské proměnné, pokud nejsou statické (více to probereme v kapitole 6).

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

199

Události aplikace V souboru global.asax se zpracovávají dva druhy událostí:

• •

Události, k nimž dochází vždy, pro každý požadavek. Vztahují se k požadavku a k odpovědi na něj.

Události, k nimž dochází pouze za určitých podmínek.

Sled událostí aplikace je následující: 1.

Application_BeginRequest(). Zavolá se při startu každého požadavku, včetně požadavků na soubory, které nejsou webovými formuláři, jako třeba webové služby.

2.

Application_AuthenticateRequest(). Zavolá se těsně předtím, než se provede autentizace. Je to přesně ten bod, kde můžete vskočit do zpracování s vaší vlastní autentizační logikou.

3.

Application_AuthorizeRequest(). Zavolá se poté, co byl uživatel autentizován (tedy identifikován; byla ověřena jeho totožnost), a kdy je třeba určit jeho oprávnění. Pomocí této metody můžete přiřazovat speciální oprávnění.

4.

Application_ResolveRequestCache(). Běžně se používá v součinnosti s ukládáním výstupu do cache (output caching). Když se výstup ukládá do cache (popisujeme to v kapitole 11), je realizovaný HTML kód webového formuláře opětovně využíván, aniž by bylo nutné vykonávat nějaký váš kód.

Přesto se tento ovladač spustí.

5.

V tomto okamžiku se požadavek podá patřičnému ovladači. Například u požadavku na nějaký webový formulář je to okamžik, kdy se stránka zkompiluje (pokud je to nutné) a vytvoří se její instance.

6.

Application_AcquireRequestState(). Zavolá se těsně předtím, než se pro klienta získají informace specifické pro relaci a naplní se jimi kolekce Session.

7.

Application_PreRequestHandlerExecute(). Zavolá se předtím, než patřičný ovladač HTTP vykoná požadavek.

8.

V tomto okamžiku patřičný ovladač vykoná požadavek. Pokud se například jedná o požadavek na webový formulář, vykoná se kód stránky pro zpracování událostí, a stránka se realizuje do HTML.

9.

Application_PostRequestHandlerExecute(). Zavolá se ihned poté, co se požadavek zpracoval.

10. Application_ReleaseRequestState(). Zavolá se, když je potřeba serializovat informace specifické pro relaci (session) z kolekce Session, aby byly dostupné pro příští požadavek.

11. Application_UpdateRequestCache(). Zavolá se těsně předtím, než se informace předají do cache pro výstup. Pokud například pro nějakou webovou stránku zapnete ukládání výstupu do cache (output caching), ASP.NET v tomto okamžiku vloží realizovanou HTML stránku do cache.

12. Application_EndRequest(). Zavolá se na konci požadavku – těsně předtím, než se uvolní a znovu vyžádají objekty. Toto je vhodná chvíle pro čistící (cleanup) kód.

Proces zpracování jediného požadavku vidíte na obrázku 5-1.

200

Kapitola 5 – Aplikace ASP.NET

Obrázek 5-1. Události aplikace.

Některé z událostí se neodpalují při každém požadavku:

•

Application_Start(). Zavolá se, když aplikace startuje poprvé a když se vytvořila doména aplikace.

Tento ovladač události je šikovným místem pro inicializační kód týkající se celé aplikace. Například byste zde mohli načíst a uložit do cache taková data, která se v průběhu doby života aplikace nebudou měnit, jako třeba stromy navigace, statické katalogy výrobků atd.

•

Session_Start(). Zavolá se pokaždé, když začne nějaká nová relace. Často se používá pro inicializaci informací specifických pro daného uživatele. Relace a správa stavu se probírají v šesté kapitole.

• •

Application_Error(). Zavolá se, jakmile dojde v aplikaci k nějaké nezpracované výjimce.

•

Application_End(). Zavolá se těsně předtím, než aplikace skončí. Konec aplikace může nastat třeba proto, že se restartovalo IIS, nebo proto, že se aplikace přenáší do nové domény aplikace, jako reakce na aktualizaci souborů, nebo také z toho důvodu, že se jedná o proces recyklace nastavení.

•

Application_Disposed(). Zavolá se za nějakou chvíli poté, co byla aplikace ukončena a svoz odpadků .NET (garbage collector) se chystá vyžádat si tu část paměti, kterou zabírala aplikace. Zde už je pozdě na důležité údržbové akce, nicméně tuto událost můžete použít jako opatření poslední záchrany při nějakém selhání, pro ověření, zdali byly uvolněny kritické zdroje.

Session_End(). Zavolá se pokaždé, když končí relace uživatele. Relace končí, když ji explicitně uvolní váš kód, nebo když vyprší platnost relace, kdy po stanovenou dobu nedorazily žádné další požadavky (obvykle je to 20 minut). Metoda se obvykle používá pro údržbové práce na datech, kterých se to týká.

Pomocí událostí aplikace se běžně provádějí inicializace, údržbové akce, přihlašování uživatelů, profilování nebo řešení různých problémů. Nemyslete si ale, že vaše aplikace budou muset používat globální události aplikace. Mnohé aplikace ASP.NET soubor global.asax nepoužívají vůbec.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

201

TIP Soubor global.asax není jediným možným místem, kde se dá reagovat na globální události aplikace.

Můžete například vytvořit vlastní moduly, které budou participovat při zpracování webových požadavků, což probereme později v této kapitole, v oddílu popisujícím rozšíření kanálu HTTP.

Ukázka zpracování událostí aplikace Následující webová aplikace používá soubor global.asax, který reaguje na metodu Application_Error. Chyba je zachycena a informace o ní jsou zobrazeny v předdefinovaném formátu. <script language="C#" runat="server"> protected void Application_Error(Object sender, EventArgs e) { Response.Write("<b>"); Response.Write("Oops! Looks like an error occurred!!</b><hr />"); Response.Write(Server.GetLastError().Message.ToString()); Response.Write("<hr />" + Server.GetLastError().ToString()); Server.ClearError(); } </script>

Abyste mohli tento ovladač události aplikace otestovat, musíte vytvořit webovou stránku, která způsobí chybu. Podívejte se na ukázku, kde se chyba vygeneruje při pokusu dělit nulou (v okamžiku načítání stránky): protected void Page_Load(object sender, EventArgs e) { int i = 0; int j = 1; int k = j/i; }

Pokud budete tuto stránku požadovat, uvidíte to, co ukazuje obrázek 5-2.

Obrázek 5-2. Zachycení nezpracované chyby.

202

Kapitola 5 – Aplikace ASP.NET

Není ovšem typické řídit vzhled webových stránek metodou Application_Error(), protože neposkytuje dostatek flexibility, kterou potřebujete při výskytu různých druhů chyb (aniž byste museli psát bolestně pracnou podmínkovou logiku). Patrně to uděláte tak, že si pomocí souboru web.config nakonfigurujete vlastní chybové stránky (popisujeme se to v příštím oddílu). Application_Error() však může být nesmírně prospěšná, chcete-li protokolovat výskyt nějakých chyb pro potřeby budoucích referencí, nebo informace o nich dokonce odesílat e-mailem systémovému administrátorovi. A vskutku – v mnoha situacích budete tuto techniku potřebovat, například tehdy, nebude-li dostupný objekt Response. Dvě z těchto situací jsou metody Application_Start() a Application_End().

Konfigurace ASP.NET Konfigurace se v ASP.NET řídí pomocí souborů XML. V těchto konfiguračních souborech jsou uloženy nejenom všechny informace, které jsou potřebné pro nastavení klíčových nastavení ASP.NET, ale také i vaše vlastní nastavení, která jsou specifická pro vaši aplikaci.

Konfigurační soubory ASP.NET mají oproti konfiguračním souborům v klasickém ASP několik následujících předností:

•

Nikdy nejsou uzamčeny. Jak jsme uvedli na začátku kapitoly, konfigurační nastavení můžete aktualizovat kdykoliv, když to potřebujete, přičemž ASP.NET hladce přejde do nové domény aplikace.

•

Snadno se k nim přistupuje a snadno se replikují. Za předpokladu, že máte přidělena patřičná síťová oprávnění, můžete konfigurační soubor modifikovat ze vzdáleného počítače (nebo jej nahradit tak, že pomocí FTP nahraje jeho novou verzi). Konfigurační soubor můžete také zkopírovat, pokud chcete použít identická nastavení v jiné aplikaci nebo na jiném webovém serveru, který provozuje stejnou aplikaci v rámci webové farmy.

•

Snadno se editují a chápou. Nastavení v konfiguračním souboru jsou srozumitelná pro lidi, což znamená, že je možné je jak editovat, tak i pochopit, aniž by byl k tomu potřebný nějaký specializovaný konfigurační nástroj.

S ASP.NET se nemusíte starat o konfiguraci metabáze IIS nebo o restarty webového serveru. Přesto však existuje několik věcí, které v souboru web.config dělat nemůžete. Nemůžete například vytvořit nebo odstranit virtuální adresář. Obdobně také nemůžete změnit mapování souborů. Chcete-li, aby služba ASP.NET zpracovávala požadavky i jiných typů souborů (jako třeba HTML nebo vaše vlastní typy souborů, které si nadefinujete), musíte k tomu použít manažera IIS, což je více popsáno v kapitole 18.

Soubor machine.config Konfigurace začíná souborem, který se jmenuje machine.config, a sídlí v adresáři c:\[WinDir]\Microsoft.

NET\Framework\[Verze]\Config. V souboru machine.config se definují podporované sekce konfiguračního souboru, konfiguruje se zpracovatelský proces ASP.NET a registrují se poskytovatelé, kteří se budou používat pro pokročilé schopnosti, jako jsou profily, členství a bezpečnost založená na rolích.

V ASP.NET 2.0 byl soubor machine.config dramaticky zprůhledněn. Aby se proces inicializace optimalizoval, mnohé z výchozích nastavení, které se dříve používaly v souboru machine.config, se nyní inicializují programátorsky. Pořád si však můžete vyhledat všechna relevantní nastavení, otevřete-li nový soubor machine. config.comments, který naleznete ve stejném adresáři. Obsahuje úplný text výchozích nastavení společně s komentáři (je to vlastně obdoba souboru machine.config v ASP.NET 1.x). V souboru machine.config.com-

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

203

ments se tedy dozvíte, jaká jsou výchozí nastavení a co znamenají, přičemž hodnoty, které potlačí tato výchozí nastavení, můžete poté přidat do souboru machine.config.

Spolu se souborem machine.config používá ASP.NET 2.0 kořenový soubor web.config (ve stejném adresáři), který obsahuje dodatečná nastavení. Tato nastavení registrují klíčové ovladače a moduly HTTP ASP.NET, připravují pravidla pro podporu prohlížečů, a definují bezpečnostní politiku. V ASP.NET 1.x byla všechna nastavení tohoto druhu umístěna v souboru machine.config.

Všechny webové aplikace na počítači dědí nastavení z obou těchto souborů. Většina z těchto nastavení jsou však v podstatě podpůrnými konstrukcemi, kterých se nemusíte nikdy dotknout. Dvě nejběžnější výjimky si probereme nyní.

<processModel> Tato sekce umožňuje nakonfigurovat, jak bude zpracovatelský proces ASP.NET recyklovat domény aplikace, a účet Windows, pod kterým se bude proces vykonávat, což určuje jeho privilegia. Používáte-li IIS 6 (což je verze IIS umístěná ve Windows 2003 Server), budou se mnohá z těchto nastavení ignorovat, protože obdobná nastavení je možné nakonfigurovat prostřednictvím manažera IIS. Další informace o prvku <processModel> najdete v kapitole 18.

<machineKey> Tato sekce umožňuje nastavit specifický klíč serveru, který se bude používat pro zašifrování dat a vytváření digitálních podpisů. Šifrování se dá používat v součinnosti s několika schopnostmi ASP.NET. ASP.NET je používá automaticky, aby ochránil cookie formulářové autentizace, a vy je můžete rovněž používat, pokud chcete ochránit data stavu zobrazení (view state) (popisuje se v kapitole 6). Klíč se také používá při autentizaci s poskytovateli stavu relace, kteří pracují vně procesu.

Obvykle má prvek <machineKey> následující tvar: <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1" />

Hodnota AutoGenerate,IsolateApps vyjadřuje, že ASP.NET bude vytvářet a ukládat klíče, které jsou specifické vzhledem ke stroji a aplikaci. Jinak řečeno – každá aplikace bude používat odlišný, automaticky vygenerovaný klíč. Tím se zabraňuje potenciálním útokům vedeným z jednoho webu na jiný web.

Nepotřebujete-li klíče specifické pro jednotlivé aplikace, můžete zvolit jediný pro všechny aplikace na aktuálním počítači takto: <machineKey validationKey="AutoGenerate" decryptionKey="AutoGenerate" validation="SHA1" />

Pokud provozuje webovou farmu a jedna aplikace běží na několika počítačích, v obou případech ovšem narazíte na problém. Požadujete např. nějakou stránku, kterou zpracuje jeden server. Stránka se pak odešle zpět na server, nicméně nyní ji zpracuje úplně jiný server, a ten nebude schopen dešifrovat stav zobrazení a cookie formulářové autentizace z prvního serveru. To kvůli tomu, že každý z webových serverů používá jiné klíče.

Abyste tuto záležitost vyřešili, je potřeba, abyste klíč explicitně nadefinovali v souboru machine.config. Podívejte se na ukázku prvku <machineKey>, ve které jsou oba důležité atributy nadefinovány:

204

Kapitola 5 – Aplikace ASP.NET

<machineKey validationKey="61EA54E005915332011232149A2EEB317586824B265326CCDB3AD9A BDBE9D6F24B0625547769E835539AD3882D3DA88896EA531CC7AFE664866BD5242FC2B05D" decrypt ionKey="61EA54E005915332011232149A2EEB317586824B265337AF" validation="SHA1" />

TIP Takto explicitně lze také nadefinovat klíče specifické pro konkrétní aplikace tím, že přidáte explicitně vytvořený prvek <machineKey> do souboru web.config, který se nachází ve virtuálním adresáři aplikace. Tento přístup budete potřebovat, pokud se ocitnete v situaci, ve které jde o kombinaci obou scénářů popsaných výše.

Například to budete potřebovat tehdy, provozujete-li svou aplikaci na několika serverech, a tyto servery současně hostují více webových aplikací, které potřebují individuální klíče.

Hodnota validationKey může být dlouhá v rozsahu od 40 do 128 znaků. Důrazně se doporučuje, abyste používali maximální dostupnou délku. Hodnota decryptionKey může být 16, nebo 48 znaků dlouhá. Bude-li to 16 znaků, bude pro zašifrování použit standard DES (Data Encryption Standard). Bude-li to 48 znaků, použije se Triple DES (neboli 3DES). (Což znamená, že se DES aplikuje třikrát za sebou.) 3DES se luští mnohem obtížněji než DES, takže se doporučuje, abyste pro decryptionKey vždy používali 48 znaků. Je-li délka některého z obou klíčů mimo povolené meze, a pokud budou kladeny na aplikaci nějaké požadavky, bude ASP.NET vracet stránku s chybovou zprávou.

Nemá valnou cenu vytvářet své vlastní ověřovací a dešifrovací klíče. Budete-li to dělat, nebudou pravděpodobně dostatečně náhodné, čímž budou zranitelnější proti některým druhům útoků, takže je lepší generovat silné náhodné klíče pomocí kódu a kryptografických tříd .NET Frameworku (z jmenného prostoru System.

Security.Cryptography).

Následující ukázka je obecný kód rutiny s názvem CreateMachineKey(), která vytvoří náhodnou posloupnost bajtů pomocí kryptograficky silného generátoru náhodných čísel. Metoda CreateMachineKey() přebírá jediný parametr, který udává, kolik znaků se má použít. Návratová hodnota je v hexadecimálním formátu, který se požaduje v souboru machine.config. public static string CreateMachineKey(int length) { byte[] random = new byte[length/2]; // Vytvoří kryptograficky silný generátor náhodných čísel.

RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); // Naplní pole bajtů náhodnými bajty. rng.GetBytes(random); // Vytvoří objekt StringBuilder, ve kterém bude udržovat výsledky, // jakmile se převedou do hexadecimálního formátu System.Text.StringBuilder machineKey = new System.Text.StringBuilder(length); // Projde v cyklu pole náhodných bajtů a přidává postupně // jednotlivé hodnoty do objektu StringBuilder. for (int i = 0; i < random.Length; i++) { machineKey.Append(String.Format("{0:X2}", random[i])); } return machineKey.ToString(); }

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

205

Tuto funkci můžete použít ve svém webovém formuláři pro vytvoření potřebných klíčů. Například následující fragment kódu vytvoří dešifrovací klíč dlouhý 48 znaků a ověřovací klíč dlouhý 128 znaků. Každou z obou hodnot pak zobrazí v oddělených textových polích: txtDecryptionKey.Text = CreateMachineKey(48); txtValidationKey.Text = CreateMachineKey(128);

Vytvořené informace můžete zkopírovat a vložit do souboru machine.config každého počítače ve webové farmě. Je to mnohem pohodlnější a bezpečnější postup, než vytvářet klíče ručně. O kryptografických třídách z jmenného prostoru System.Security.Cryptography se více dozvíte v kapitole 25.

Soubor web.config Každá webová aplikace dědí nastavení ze souboru machine.config. Kromě toho můžete použít i nastavení specifické pro jednotlivé aplikace. Například tehdy, když chcete nastavit konkrétní metodu pro autentizaci, typ ladění, výchozí jazyk nebo vlastní chybové stránky. Je však důležité, abyste si uvědomili, že v souboru machine.config jsou některá nastavení, která nemůžete potlačit. Některá nastavení, jako jsou nastavení modelu procesu, se nedají měnit na úrovni aplikace. Některá nastavení také mohou být specifická pro konkrétní aplikaci. Používáte-li taková nastavení, musíte umístit soubor web.config do kořenového adresáře své aplikace (nikoliv do libovolného podadresáře).

Celý obsah konfiguračního souboru ASP.NET je vnořen do kořenového prvku <configuration>. Tento prvek obsahuje prvek <system.web>, který se používá pro nastavení ASP.NET. Uvnitř prvku <system.web> jsou pak oddělené prvky určené pro každý aspekt konfigurace.

Základní kostra souboru web.config vypadá takto: <?xml version="1.0" encoding="utf-8" ?> <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <system.web> <!-- sem přijdou konfigurační sekce ASP.NET. --> </system.web> </configuration>

ASP.NET používá vícevrstvý konfigurační systém, který umožňuje používat pro různé části aplikace různá nastavení. Chcete-li tento systém používat, musíte přidat do svého virtuálního adresáře dodatečné podadresáře. Ty pak mohou obsahovat své vlastní konfigurační soubory web.config s dodatečnými nastaveními. ASP. NET používá dědění těchto konfigurací, takže každý podadresář obdrží nastavení z rodičovského adresáře.

Dejme tomu, že máme webový požadavek http://localhost/A/B/C/MojeStranka.aspx, kde A je kořenový adresář webové aplikace. V tomto případě se do hry zapojují nastavení z několika úrovní: 1.

Nejprve se použijí výchozí nastavení z machine.config.

2.

Pak se aplikují nastavení web.config z kořenového adresáře počítače. Tento soubor web.config je ve stejné složce CONFIG jako soubor machine.config.

3.

Je-li nějaký soubor web.config v kořenu aplikace A, jeho nastavení se uplatní nyní.

4.

Je-li nějaký soubor web.config v podadresáři B, jeho nastavení se uplatní nyní.

5.

Je-li nějaký soubor web.config v podadresáři C, uplatní se jeho nastavení jako poslední.

206

Kapitola 5 – Aplikace ASP.NET

K této posloupnosti je důležité připomenout, že ačkoliv můžete mít neomezený počet podadresářů, jsou významná zejména nastavení použitá v krocích 1 a 2. Je to proto, že některá nastavení se dají použít pouze na úrovni machine.config (jako je účet Windows, pod kterým se bude kód vykonávat), a jiná nastavení lze zase použít pouze na úrovni aplikace (jako je druh autentizace, kterou bude používat vaše webová aplikace).

Obrázek 5-3. Dědění konfigurací.

V podadresářích je tak možné specifikovat pouze malou podmnožinu nastavení, která se liší od zbytku webové aplikace. Jedním z důvodů, proč je někdy žádoucí použít v aplikaci několik podadresářů, jsou různá nastavení týkající se bezpečnosti. Soubory, které je potřeba zabezpečit, by se umístily do speciálního adresáře s takovým souborem web.config, který byl definoval přísnější bezpečnostní nastavení, než jaká jsou použita v kořenovém virtuálním adresáři.

Pokud jsou nějaká nastavení ve vzájemném rozporu, nastavení ve více vnořeném souboru vždy přepíše nastavení zděděné z rodiče. Až na jednu výjimku – je možné vyznačit konkrétní uzamčené sekce, které nebude možné měnit. Příslušnou techniku popisujeme v následujícím oddílu.

Práce s prvky <location> Prvek <location> je rozšíření, které umožňuje specifikovat v jednom konfiguračním souboru více než jednu skupinu nastavení. Podadresář nebo soubor, odkud se budou nastavení aplikovat, specifikujete atributem path prvku <location>.

Například následující soubor web.config vytváří pomocí prvku <location> dvě skupiny nastavení – jedno, které je určeno pro aktuální adresář, a druhé, které se bude aplikovat pouze na soubory umístěné z podadresáři Secure: <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <system.web> <!-- Sem přijdou základní konfigurační nastavení. --> </system.web> <location path="/Secure"> <system.web>

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

207

<!-- Sem přijdou konfigurační nastavení pro podadresář Secure. --> </system.web> </location> </configuration>

Tento soubor web.config v podstatě zastává roli dvou konfiguračních souborů. Funguje stejně, jako kdybyste nastavení rozdělili do dvou oddělených souborů web.config, a jeden z nich dali do podadresáře Secure.

Není stanoven žádný limit na počet prvků <location> v jednom konfiguračním souboru. Prvek <location> se však příliš často nepoužívá, protože konfigurační nastavení se obvykle snadněji spravují a aktualizují, když se udržují v oddělených souborech. Existuje však jedna situace, kdy prvek <location> poskytuje takovou funkcionalitu, které žádným jiným způsobem nedosáhnete. Je to tehdy, když uzamknete nějaké konkrétní nastavení, aby se nedalo potlačit.

Abyste pochopili, jak tato technika funguje, zamyslete se nad následujícím příkladem, ve kterém definuji dvě skupiny nastavení, přičemž jsem v jedné skupině nastavil atribut allowOverride značky <location> na hodnotu false. Je to pěkně vidět v následujícím kódu: <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <system.web> <!-- Sem přijdou nechráněná konfigurační nastavení. --> </system.web> <location allowOverride="false" > <system.web> <!-- Sem přijdou uzamčená konfigurační nastavení. --> </system.web> </location> </configuration>

V tomto případě není možné potlačit žádné nastavení ze sekce <location>. Pokud se o to pokusíte, a budete ve své aplikaci požadovat nějakou stránku, ASP.NET vám vygeneruje nezpracovanou výjimku.

Atribut allowOverride prvku <location> je primárně určen pro potřeby webhostingových firem, které si chtějí být jisté, že určité nastavení nebude možné změnit. V těchto případech administrátor upraví soubor machine. config na webovém serveru tak, že pomocí prvku <location> uzamkne všechny sekce souboru web.config, které chce ochránit.

TIP Když uzamykáte nastavení v souboru machine.config, máte dvě možnosti. Zaprvé, můžete uzamknout nastavení pro všechny aplikace tím, že neuvedete atribut path značky <location>. Zadruhé, můžete uzamknout nastavení pro konkrétní webovou aplikaci, když nastavíte atribut path na její název.

Konfigurační nastavení Prvek <system.web> obsahuje všechna konfigurační nastavení specifická pro ASP.NET. Specifikuje různé aspekty webové aplikace a zapíná služby, jako je bezpečnost, správa stavu a trasování.

Základní dceřiné prvky, které může prvek <system.web> obsahovat, a jejich účel, jsou uvedeny v tabulce 5-2.

Seznam nicméně není úplný. Jeho účelem je vám dát pouze hrubou představu o rozsahu konfigurace ASP. NET.

KAPITOLA 11 Ukládání do cache Jednou z nejcennějších schopností ASP.NET 1.x bylo ukládání do cache, a v ASP.NET 2.0 je to ještě mnohem lepší.

Anglicky se tomu říká caching a jedná se o dočasné uchovávání kopií informací v jisté, k tomuto účelu vyhrazené paměti (cache), když je opětovné vytváření takových informací v nějakém ohledu nákladné. Do cache se mohou například ukládat výsledky komplikovaných dotazů, aby následné požadavky vůbec nemusely přistupovat k příslušné databázi. Místo toho si shrábnou patřičný objekt výsledků přímo z paměti serveru, což je mnohem rychlejší. Skutečný půvab této techniky ale spočívá v tom, že na rozdíl od mnoha jiných technik pro zvýšení výkonu, zesiluje nejenom výkon, ale i škálovatelnost (scalability). Výkon je vyšší proto, že dramaticky klesá čas potřebný na získání informací. Škálovatelnost se zlepšuje proto, že obcházíte úzká hrdla, jako je databázové připojení, kde mohou vznikat zácpy. Využitím cache docílíte toho, že aplikace bude moci simultánně obsluhovat více požadavků na stránku s menším počtem databázových operací.

Samozřejmě – ukládat informace do paměti není vždy ten nejlepší nápad. Paměť serveru je zdroj, který má své limity, a pokud se tam pokusíte nacpat příliš mnoho informací, část informací se bude stránkovat na disk, což může potenciálně zapříčinit zpomalení celého systému. To je také důvodem, proč nejlepší strategie pro dočasné uchovávání kopií informací (kam také patří ty, které jsou napevno zapojeny do ASP.NET) omezují samy sebe. Když ukládáte informace do nějaké cache, obvykle očekáváte, že je tam při budoucím požadavku také najdete. Jaká však bude doba života těchto informací, to už podle vlastního uvážení rozhoduje server. Jestliže se cache naplní, nebo aplikace spotřebovává velké množství paměti, informace se budou selektivně z cache odstraňovat, aby byl stále zajištěn požadovaný výkon. Takže můžeme říci, že právě soběstačnost je přesně to, co činí z ukládání do cache tak mocný zdroj.

S ASP.NET máte prvotřídní techniku ukládání do cache zdarma, s řadou zajímavých voleb. Můžete si do cache uschovat kompletně realizovaný HTML výstup stránky, nebo část takového HTML, nebo libovolné objekty. Můžete si také přizpůsobit expirační politiky a připravit různé závislosti (dependencies), aby se položky z cache automaticky odstraňovaly na základě toho, že byly modifikovány jiné zdroje – jako jsou objekty souborů a databázových tabulek.

452

Kapitola 11 – Ukládání do cache

ZMĚNY TÝKAJÍCÍ SE UKLÁDÁNÍ DO CACHE V .NET 2.0 Už tak dost působivý model ukládání do cache se v ASP.NET 2.0 ještě více zdokonalil. V následujícím výčtu je uveden seznam změn v pořadí, v jakém se probírají v této kapitole:

•

Ovládací prvek Substitution. S jeho pomocí se definuje nějaký dynamický obsah na stránce, jejíž realizovaný HTML výstup se ukládá do cache. Konečným výsledkem je to, že se dynamický obsah realizuje vždy při běhu, i když se zbytek stránky získává z cache.

•

Profily cache. Správa webu obsahujícího desítky stránek ukládaných do cache může být dost ipracná, protože potřebujete-li nějak upravit na míru nějaká nastavení, která se týkají ukládání do cache, budete muset upravit každou stránku. S profily cache definujete svá nastavení v souboru web.config a aplikujete dávkově na stránky.

•

Cachování výstupu na disk. Nyní můžete ASP.NET explicitně říci, aby uschovával kopie informací nejenom do paměti, ale i na disk. Uložené prvky pak mohou přežívat mnohem déle – i když se z paměti odstraní, nebo se restartuje aplikace. Ukládání kopií informací na disk je standardně zapnuto, další konfigurace nebo vypnutí této volby je pochopitelně možné.

•

Závislosti cache na SQL (SQL cache dependencies). Kritériem pro odstranění kopií datových objektů uložených v cache může být to, že se změnila odpovídající data v databázi. Je to jedna z nejžhavějších nových schopností ASP.NET.

•

Vlastní závislosti (custom dependencies). Potřebujete automaticky zrušit platnost prvků, které máte uložené v cache, když se změní nějaké jiné zdroje? Nyní je třída CacheDependency nezapečetěná (unsealed), takže z ní můžete odvozovat vaše vlastní závislosti.

Všechny výše uvedené inovace se probírají v této kapitole.

Chápeme cachování v ASP.NET Mnozí vývojáři často považují cachování dat v paměti za jednu z parádiček produktu, a nikoliv za něco skutečně užitečného. Tento názor je ovšem velmi vzdálen skutečnému významu této techniky. Když se cachování využívá inteligentně, dokáže zvýšit výkon dvakrát, třikrát, a někdy i desetkrát, i když se důležitá data ukládají pouze na krátkou dobu.

V ASP.NET existují dva způsoby cachování informací. Vaše aplikace může, a také by měla, využívat oba způsoby, protože se vzájemně doplňují:

•

Cachování výstupu (output caching). Nejjednodušší varianta. Ukládá se kopie finálně realizované stránky HTML, která se odesílá klientovi. Příští klient, který vyšle požadavek na tuto stránku, ji vlastně nespustí. Místo toho se automaticky odešle finální výstup HTML. Ušetří se tím veškerý čas, který by byl jinak zapotřebí na spuštění stránky a vykonání jejího kódu.

•

Cachování dat (data caching). Dá se provádět ručně z kódu. Do cache se uchovávají důležité informace, jejichž rekonstrukce je náročná na čas (například sada dat načítaná z databáze). Ostatní stránky mohou ověřovat, zdali už tyto informace existují, a použít je, takže se mohou vyhnout obvyklým krokům, které je jinak potřeba provést, aby se informace získaly. Cachování dat je sice koncepčně stejné jako využívání stavu aplikace, nicméně je mnohem přívětivější k serveru, protože se prvky budou z cache odstraňovat automaticky, jestliže jejich objem naroste natolik, aby to mělo nepříznivý vliv na výkon. Prvky lze také nastavit tak, aby jejich doba života vypršela automaticky.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

453

Nad těmito modely jsou vybudovány dva specializované typy ukládání do cache:

•

Cachování fragmentu (fragment caching). Jedná se o specializovaný typ cachování výstupu – neukládá se kopie HTML výstupu celé stránky, ale pouze část HTML. Cachování fragmentů funguje tak, že se ukládá realizovaný výstup HTML nějakého uživatelského ovládacího prvku (user control) na stránce. Až se bude stránka vykonávat příště, budou se odpalovat stejné události stránky (takže opět poběží kód stránky), ale kód pro odpovídající uživatelský ovládací prvek se vykonávat nebude.

•

Cachování zdroje dat (data source caching). Jedná se o techniku, která je zabudovaná do ovládacích prvků pro zdroje dat, což jsou SqlDataSource, ObjectDataSource a XmlDataSource. Formálně se při cachování zdroje dat pracuje s technikou cachování dat (data caching). Rozdíl je v tom, že proces není třeba zpracovávat explicitně. Prostě jen nakonfigurujete patřičné vlastnosti a ovládací prvek zdroje dat se sám bude starat o uschovávání dat do cache a získávání dat z cache.

V této kapitole se probírají všechny volby, které máte pro ukládání do cache k dispozici. Nejprve probereme základy cachování výstupu a dat. Pak se podíváme, jak se řeší ukládání do cache v ovládacích prvcích pro zdroje dat. A nakonec prozkoumáme jednu z nejžhavějších novinek ASP.NET – spojení cachovaných položek pro tabulky v databázi se závislostmi cache SQL.

Cachování výstupu Při cachování výstupu (output caching) se do cache ukládá finálně realizovaný HTML kód stránky. Když se později požaduje tatáž stránka, nevytvářejí se objekty ovládacích prvků, nenastartuje se životní cyklus stránky a nevykoná se žádný váš kód. K obsluze se využije HTML kód uložený v cache. Je jasné, že cachování výstupu teoreticky zvyšuje výkon maximálním způsobem, protože veškerá zátěž, kterou vnáší váš kód, je pryč.

POZNÁMKA Stránka ASP.NET může využívat další statické prostředky (jako jsou obrázky), které ASP.NET zpracovávat nebude. O cachování těchto prvků se nestarejte. To automaticky zařídí IIS, který umí cachovat soubory efektivnějším způsobem, než cache ASP.NET.

Deklarativní cachování výstupu Abyste viděli cachování výstupu v akci, vytvořte stránku, která zobrazí aktuální čas, viz obrázek 11-1.

Obrázek 11-1. Cachování celé stránky.

454

Kapitola 11 – Ukládání do cache

Kód stránky je průzračný. Nastaví prostě datum, které se objeví v popisku, když se odpálí událost Page.Load: protected void Page_Load(Object sender, EventArgs e) { lblDate.Text = "The time is now:<br />"; lblDate.Text += DateTime.Now.ToString(); }

Existují dva způsoby, jak přidat stránku do výstupu cache. Nejběžnější způsob je vložit na začátek souboru .aspx direktivu OutputCache, jako zde: <%@ OutputCache Duration="20" VaryByParam="None" %>

Atribut Duration zde dává ASP.NET pokyn, aby uchoval stránku v cache po dobu 20 vteřin. Atribut VaryByParam je povinný a jeho efekt budeme probírat až v příštím oddílu.

Když testovací stránku spustíte, odhalíte určité zajímavé chování. Když ke stránce přistoupíte poprvé, zobrazí se aktuální čas. Budete-li stránku aktualizovat o malou chvilku později, stránka se aktualizovat nebude.

Místo toho vám ASP.NET automaticky pošle HTML kód stránky, která je uložena v cache (za předpokladu, že neuplynulo 20 vteřin, a tudíž ještě nevypršela platnost stránky v cache). Když vyprší platnost cachované stránky, ASP.NET spustí znovu kód stránky, uloží do cache novou kopii stránky, a bude ji používat po dalších 20 vteřin.

Dvacet vteřin se někomu může zdát jako bezvýznamná doba, ale u webu s hustým provozem to může mít dramatický efekt. Do cache můžete například uložit stránku, která poskytuje seznam výrobků z nějakého katalogu. Tím, že máte kopii stránky uloženou v cache po dobu 20 vteřin, bude stačit, aby stránka prováděla tři databázové operace za minutu. Kdybyste kopii stránky do cache neukládali, pokoušela by se stránka připojovat k databázi pro každý požadavek klienta, což by snadno mohlo vést k několika desítkám požadavkům za minutu pro přístup k databázi.

Samozřejmě – jenom kvůli tomu, že požadujete, aby byla kopie stránky uložena po dobu 20 vteřin, nutně neznamená, že tomu tak skutečně bude. Stránka může být vyklizena z cache dříve, pokud systém zjistí, že začíná být nouze o paměť. To znamená, že ukládání výstupu stránek do cache můžete používat celkem bezstarostně a nemusíte se dělat přílišné starosti s tím, zdali vaše aplikace není brzdou výkonu, protože používá příliš mnoho paměti životně důležité pro provoz.

TIP Když překompilujete nějakou stránku, jejíž kopii máte uloženou v cache, ASP.NET tuto stránku automaticky odstraní z cache. Tím se zabraňuje potížím, které by vznikaly kvůli tomu, že stránka nebyla řádně aktualizována, protože se použila její starší kopie z cache. Když ale testujete svou aplikaci, bývá dobré ukládání kopií stránek vypnout. Jinak se totiž můžete dostat do nesnází, používáte-li sledování proměnných, zarážky a jiné ladicí techniky, protože se váš kód nebude vykonávat, je-li k dispozici kopie stránky uložená v cache.

Cachování a dotazovací řetězec Jedním z hlavních zdrojů úvah při cachování je rozhodnutí, kdy se dá stránka opětovně použít, a kdy musejí být informace na sekundu aktuální. Vývojáři, kteří nesmírně touží po okamžitém ukojení svých vášní (a trpí nedostatkem trpělivosti), obvykle přeceňují význam poskytování informací v reálném čase. Obvykle můžete cachování používat bez sebemenších problémů, což vede k efektivnímu a opětovnému využívání mírně zastaralých dat, protože odměnou je velmi značné zvýšení výkonu.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

455

Samozřejmě – informace někdy musejí být dynamické. Jednou z takových situací je, když stránka používá informace z relace (session) aktuálního uživatele, aby s jejich pomocí upravila na míru rozhraní uživatele.

V tomto případě není ukládání celé stránky do cache příliš vhodné (i když lze situaci mnohdy vylepšit cachováním kopie fragmentu). Dalším takovým příkladem je stránka, která získává informace z jiné stránky prostřednictvím dotazovacího řetězce. Pak je stránka příliš dynamická na to, aby mělo smysl ji ukládat do cache – nebo tomu tak není?

V našem aktuálním příkladu je atribut VaryByParam nastaven na None, čímž vlastně ASP.NET sdělujete, že potřebujete uložit pouze jedinou kopii cachované stránky, a že to bude vyhovující pro všechny situace. Jestliže nějaký požadavek na stránku přidá k URL argumenty v podobně dotazovacího řetězce, nebude v tom žádný rozdíl – ASP.NET použije vždy stejný výstup, dokud nevyprší jeho platnost. Můžete si to otestovat. Přidejte ručně v okně prohlížeče do URL nějaký parametr ve formě dotazovacího řetězce (jako například ?a=b).

Na základě tohoto experimentu byste mohli usoudit, že cachování výstupu není vhodné pro stránky, které používají argumenty dotazovacího řetězce. ASP.NET však poskytuje ještě jinou volbu. Můžete nastavit atribut VaryByParam na *, čímž vyjádříte, že stránka používá dotazovací řetězec, a současně je to pokyn pro ASP. NET, aby do cache ukládal separátní kopie stránky pro různé argumenty dotazovacího řetězce, jako zde: <%@ OutputCache Duration="20" VaryByParam="*" %>

Když nyní požádáte o stránku s dodatečnými informacemi uvedenými v dotazovacím řetězci, ASP.NET prozkoumá dotazovací řetězec. Jestliže řetězec souhlasí s řetězcem předchozího požadavku, a v cache existuje uložená kopie stránky, bude tato opětovně použita. V jiném případě se vytvoří nová kopie stránky a uloží do cache separátně.

Abyste si udělali lepší představu o tom, jak celý proces funguje, vezměte si na paškál následující sérii požadavků: 1.

Požadujete stránku bez jakéhokoliv dotazovacího řetězce. Obdržíte kopii A dané stránky.

2.

Požadujete stránku s parametrem ProductID=1. Obdržíte kopii B dané stránky.

3.

Jiný uživatel požaduje stránku s parametrem ProductID=2. Tento uživatel obdrží kopii C dané stránky.

4.

Jiný uživatel požaduje stránku s ProductID=1. Pokud je cachovaný výstup kopie B ještě platný, odešle se tomuto uživateli.

5.

Stejný uživatel pak požaduje stránku bez dotazovacího řetězce. Jestliže ještě nevypršela platnost kopie A, odešle se tato stránka z cache.

Celé si to můžete vyzkoušet na vlastní kůži, ale asi budete muset prodloužit dobu, po kterou se udržují stránky v cache, abyste se nemuseli při testování honit.

Cachování s konkrétními parametry dotazovacího řetězce Nastavení VaryByParam="*" umožňuje využívat cachování s dynamickými stránkami, jejichž výstup je variabilní na základě dotazovacího řetězce. Tento přístup může být nesmírně prospěšný pro stránku, která obsahuje podrobné údaji o výrobku a dostává ve svém dotazovacím řetězci ID výrobku. Při ukládání do cache, které bere v úvahu parametry, můžete uložit separátní stránku pro každý výrobek, a tím ušetřit nákladné výlety do databáze. Abyste však získali nějaké výhody ze zvýšeného výkonu, pravděpodobně budete muset zvýšit dobu života cachovaných stránek na několik minut, nebo i déle.

456

Kapitola 11 – Ukládání do cache

Taková technika ovšem sebou nese potenciální nesnáze. Stránka, která v dotazovacím řetězci akceptuje širokou škálu různých parametrů (jako třeba stránka, která dostává v řetězci nějaká čísla pro nějaké výpočty, nebo informace o klientovi, nebo slova, které se mají vyhledat), není vhodná pro ukládání do cache. Počet možných variant je totiž enormní a možností opětovného využití velmi málo. I přes fakt, že stránky budou z cache odstraňovány, pokud bude nouze o paměť, může se bezděčně stát, že z cache budou důležitější informace odstraněny jako první, nebo že se zpomalí všechny další operace.

V mnoha případech je nastavení VaryByParam na zástupný znak hvězdička (*) zbytečně vágní. Obvykle je mnohem lepší, když se konkrétně specifikuje důležitá proměnná dotazovacího řetězce pomocí jejího názvu.

Tady máte ukázku: <%@ OutputCache Duration="20" VaryByParam="ProductID" %>

V tomto případě ASP.NET prozkoumá dotazovací řetězec a bude hledat parametr ProductID. Požadavky s odlišnými ProductID se budou ukládat do cache separátně, ale všechny ostatní parametry se budou ignorovat. To je užitečné hlavně tehdy, jestliže se do stránky v dotazovacím řetězci předávají ještě další informace, které daná stránka nepoužívá. ASP.NET ale bez vaší pomoci neumí rozlišit, které parametry dotazovacího řetězce jsou "důležité", a které ne.

Specifikovat můžete i několik parametrů současně. Oddělujte je středníky, jako zde: <%@ OutputCache Duration="20" VaryByParam="ProductID;CurrencyType" %>

V tomto případě se budou ukládat do cache oddělené verze pro ty dotazovací řetězce, které používají parametr ProductID nebo parametr CurrencyType.

POZNÁMKA Cachování výstupu funguje dobře u stránek, které se mění pouze na základě dat na straně serveru (například data z nějaké databáze) a dat v dotazovacích řetězcích. Nebude však dobře fungovat, jestliže výstup stránky závisí na informacích specifických pro daného uživatele, jako jsou data relace nebo cookies. Cachování výstupu dále nefunguje u stránek, které jsou řízené událostmi a používají se v nich formuláře. V těchto případech se budou události ignorovat a statické stránky budou opětovně odeslány při každém zpětném odeslání zpět na server (postback), čímž se vlastně stránka vypíná. Abyste se těchto problémů vyvarovali, používejte cachování fragmentu, místo cachování celé stránky, nebo použijte cachování dat pro uložení konkrétních informací do cache.

Vlastní řízení cachování Cachování na základě variant dotazovacích řetězců není vaší jedinou volbou, pokud chcete ukládat do cache několik verzí stránky. S ASP.NET si totiž můžete vytvořit vlastní postup, ve kterém budete rozhodovat, zdali se do cache uloží nová verze stránky, nebo zdali se opětovně použije nějaká již existující. Kód, který napíšete, prozkoumá patřičné informace, a vrátí řetězec. Ten pak ASP.NET použije pro implementaci ukládání do cache. Jestliže kód vygeneruje pro různé požadavky stejný řetězec, ASP.NET opětovně použije cachovanou stránku. Jestliže kód vygeneruje novou hodnotu řetězce, ASP.NET vygeneruje novou verzi stránky a uloží ji do cache odděleně.

Vlastní způsob cachování se hodí například tehdy, když potřebujete mít k dispozici různé verze stránky na základě typu prohlížeče. Prohlížeče Netscape pak vždy obdrží stránky optimalizované pro Netscape, uživatelé Internet Exploreru naopak získají HTML kód optimalizovaný pro Internet Explorer. Chcete-li si připravit tento druh logiky, začněte tím, že do stránek, jejichž kopie chcete ukládat do cache, přidáte direktivu Out-

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

457

putCache. Atributem VaryByCustom pak specifikujte název reprezentující typ vašeho ukládání do cache.

V následujícím příkladu je použit název browser, protože se kopie stránek budou ukládat do cache podle toho, jaký prohlížeč uživatel používá: <%@ OutputCache Duration="10" VaryByParam="None" VaryByCustom="browser" %>

Dále je potřeba, abyste vytvořili proceduru, která bude realizovat řetězec pro vlastní ukládání. Proceduru musíte zapsat do souboru global.asax dané aplikace (nebo do jejího souboru kódu v pozadí) a musí mít následující syntaxi: public override string GetVaryByCustomString(

HttpContext context, string arg)

{ // Kontrola požadovaného typu cachování výstupu do cache. if (arg == "browser") { // Určí, jaký je aktuální prohlížeč string browserName; browserName = Context.Request.Browser.Browser; browserName += Context.Request.Browser.MajorVersion.ToString(); // Ukládání do cache se bude řídit podle návratové hodnoty. return browserName; } else { base.GetVaryByCustomString(context, arg) } }

Funkce GetVaryByCustomString() předává název VaryByCustom v parametru arg. To umožňuje vytvořit aplikaci, která bude pomocí stejné funkce implementovat několik různých typů vašeho vlastního ukládání do cache. Každý odlišný typ bude používat jiný název VaryByCustom (jako jsou Browser, BrowserVersion, nebo DayOfWeek). Funkce GetVaryByCustomString() prozkoumá název VaryByCustom a vrátí patřičný řetězec, podle něhož se bude ukládání do cache řídit. Bude-li řetězec u různých požadavků stejný, ASP.NET opětovně použije kopii stránky uloženou v cache. Pokud se na to podíváme z druhého konce, ASP.NET vytvoří a uloží do cache samostatnou kopii stránky pro každý různý řetězec, který obdrží.

Je zajímavé, že základní implementace GetVaryByCustomString() už obsahuje logiku pro ukládání do cache na základě typu prohlížeče. To znamená, že nemusíte psát kód metody uvedené výše. Základní implementace GetVaryByCustomString() vytvoří řetězec na základě názvu prohlížeče a čísla hlavní verze. Chcete-li tuhle logiku změnit (například ukládat stránky do cache na základě názvu, hlavní verze a vedlejší verze prohlížeče), můžete překrýt metodu GetVaryByCustomString() v duchu návodu uvedeného v příkladu výše.

POZNÁMKA Ukládání stránek do cache podle typu prohlížeče je velmi důležitá technika pro takové stránky, které využívají nějaké specifické schopnosti daného prohlížeče. Pokud například stránka generuje takový kód JavaScript, který se provádí u klienta, a který nepodporují všechny prohlížeče, musíte udělat ukládání do cache závislé na verzi prohlížeče. Samozřejmě – stále zůstává na vašem kódu, aby identifikoval prohlížeč, a specifikoval, jaký JavaScript se bude realizovat. O adaptivních stránkách a o JavaScriptu se více dozvíte v páté části knihy.

458

Kapitola 11 – Ukládání do cache

Direktiva OutputCache má ještě třetí atribut, který se dá využít pro definování způsobu cachování. Je to atribut VaryByHeader, který umožňuje ukládat samostatné verze stránky na základě hodnoty nějakého záhlaví HTTP obdrženého s požadavkem. Můžete uvést jedno záhlaví nebo seznam záhlaví oddělovaných středníky.

Tato technika se vám může hodit u vícejazyčných webů, abyste si mohli ukládat různé verze stránky na základě jazyka klientského prohlížeče, jako třeba zde: <%@ OutputCache Duration="20" VaryByParam="None" VaryByHeader="Accept-Language" %>

Cachování s třídou HttpCachePolicy Direktiva OutputCache je všeobecně preferovanou technikou pro ukládání kopií stránek do cache, protože pokyny, které se týkají ukládání do cache, jsou odděleny od zbytku kódu. Direktiva OutputCache také snadno umožňuje konfigurovat několik vlastností na jediném řádku.

Máte však i jinou volbu – napsat kód, který bude využívat zabudovanou speciální vlastnost Response.Cache.

Ta poskytuje instanci třídy System.Web.HttpCachePolicy. Tento objekt nabízí vlastnosti umožňující zapnout cachování pro aktuální stránku.

V následujícím příkladu je stránka zobrazující datum přepsána tak, že když je stránka poprvé načtena, automaticky se zapíná cachování. Kód zapíná cachování pomocí metody SetCacheability(), která specifikuje, že stránka bude cachována na serveru a že libovolný další klient může využívat cachovanou kopii této stránky.

Metoda SetExpires() definuje expirační datum stránky a nastavuje je na aktuální čas plus 60 vteřin. protected void Page_Load(Object sender, EventArgs e) { // Kopie stránky se bude ukládat do cache na serveru.

Response.Cache.SetCacheability(HttpCacheability.Public); // Uložená kopie stránky se bude používat po dobu //následujících 60 vteřin.

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60)); // Tento dodatečný řádek zajišťuje, že prohlížeč nemůže // učinit stránku neplatnou, když uživatel klikne //na tlačítko Refresh (Aktualizovat) // (o což se některé ničemné prohlížeče pokoušejí).

Response.Cache.SetValidUntilExpires(true); lblDate.Text = "The time is now:<br />" + DateTime.Now.ToString(); }

Z hlediska návrhu není programátorské řešení cachování až tak průzračné. Vkládat kód týkající se cachování přímo do stránky je často krkolomné, a vždy jsou s tím nějaké zmatky, když potřebujete dostat do stránky ještě nějaký jiný inicializační kód. Uvědomte si, že kód v ovladači události Page.Load se vykoná jen tehdy, pokud stránka není uložená v cache (buď proto, že se jedná o první požadavek na stránku, nebo proto, že platnost naposledy cachované verze stránky už vypršela, nebo proto, že nesouhlasí parametry požadavku).

TIP Přesvědčte se, že používáte vlastnost Response.Cache stránky, a nikoliv vlastnost Cache. Vlastnost Cache se nepoužívá pro cachování výstupu – místo toho poskytuje přístup ke cache, kam se ukládají data (což se probírá v oddílu "Cachování dat").

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

459

Nahrazení po uložení do cache a cachování fragmentů Ačkoliv v některých případech zjistíte, že nemůžete do cache uložit celou stránku, můžete do ní uložit alespoň ty části, které se nemění a jejichž opětovné vytvoření je nákladné. S touto výzvou se můžete vypořádat následujícími dvěma způsoby:

•

Cachování fragmentu (fragment caching). V tomto případě pouze specifikujte obsah, který chcete uložit do cache. Zabalte ho do účelového uživatelského ovládacího prvku, a do cache uložte výstup z tohoto ovládacího prvku.

•

Nahrazení po uložení do cache (post-cache substitution). V tomto případě pouze specifikujte dynamický obsah, který nechcete ukládat do cache. Pak nahraďte tento obsah za něco jiného pomocí ovládacího prvku Substitution. Nahrazení po uložení do cache je jednou z novinek ASP.NET 2.0.

Z těchto dvou technik se snadněji implementuje cachování fragmentu. Ovšem rozhodnutí, kterou techniku nakonec použít, se bude obvykle zakládat na objemu obsahu, jehož kopie chcete uložit do cache. Máte-li malou, dobře odlišitelnou část obsahu, který chcete ukládat do cache, je rozumnější použít cachování fragmentu.

A opačně – máte-li pouze malou část dynamického obsahu, může být jednodušší nahrazovací přístup. Oba přístupy nabízejí obdobný výkon.

TIP Nejflexibilnější způsob, jak implementovat částečné cachování, je úplně se oprostit od cachování výstupu, použít cachování dat (data caching), a zpracovat celý proces programátorsky v kódu. Tuto techniku uvidíte v oddílu "Cachování dat".

Cachování fragmentu Pro implementaci cachování fragmentu do cache musíte vytvořit nějaký uživatelský ovládací prvek pro tu část stránky, kterou chcete mít v cache. Pak k tomuto uživatelskému ovládacímu prvku přidejte direktivu OutputCache. Výsledkem bude, že do cache se nebude ukládat celá stránka, ale pouze uživatelský ovládací prvek.

Uživatelské ovládací prvky se probírají v kapitole 14.

Cachování fragmentu je koncepčně stejné jako cachování stránky. Je tu pouze jeden zádrhel – pokud stránka obdrží cachovanou verzi uživatelského ovládacího prvku, nebude moci s ním komunikovat v kódu. Pokud například uživatelský ovládací prvek poskytuje vlastnosti, váš kód webové stránky nebude schopen tyto vlastnosti modifikovat, ani k nim přistupovat. Když se používá cachovaná verze uživatelského ovládacího prvku, do stránky je jednoduše vložen blok HTML kódu. Odpovídající objekt uživatelského ovládacího prvku není dostupný.

Nahrazení po uložení do cache Schopnost nahrazení po uložení do cache (post-cache substitution) (což je jedna z novinek ASP.NET 2.0) se točí okolo jediné metody, která byla přidána do třídy HttpResponse. Je to metoda WriteSubstitution(), která přijímá jediný parametr – delegáta (delegate), který ukazuje na metodu zpětného volání, kterou implementujete ve vaší třídě stránky. Metoda vrací obsah pro patřičnou část stránky.

Funguje to takto – když pracovní rámec ASP.NET stránky získá cachovanou stránku, automaticky spustí vaši metodu zpětného volání pro získání dynamického obsahu. Tento obsah je pak vložen do cachovaného HTML kódu stránky. Pěkné na tom je to, že i když vaše stránka ještě nebyla uložena do cache (například proto, že se realizovala úplně poprvé), ASP.NET i přesto zavolá stejným způsobem vaši metodu zpětného volání pro

460

Kapitola 11 – Ukládání do cache

získání dynamického obsahu. V podstatě je celý vtip v tom, že vytvoříte nějakou metodu, která generuje nějaký dynamický obsah, a tím, že to uděláte, garantujete, že se vaše metoda vždy zavolá, a že její obsah nebude nikdy cachován.

Metoda, která generuje dynamický obsah, musí být statická. Je to z toho důvodu, že ASP.NET musí být schopno zavolat tuto metodu, i když ještě není k dispozici instance třídy stránky. (Je zřejmé, že pokud se stránka obsluhuje z cache, objekt stránky se nevytvoří.) Signatura metody je poměrně průzračná – přijímá objekt HttpContext reprezentující aktuální požadavek a vrací řetězec s novým kódem HTML. Podívejte se na ukázku, která vrací tučně naformátované datum: private static string GetDate(HttpContext context) { return "<b>" + DateTime.Now.ToString() + "</b>"; }

Pokud toto chcete dostat do stránky, je potřeba na vhodném místě zavolat metodu Response.WriteSubstitution(): protected void Page_Load(object sender, EventArgs e) { Response.Write("This date is cached with the page: "); Response.Write(DateTime.Now.ToString() + "<br />"); Response.Write("This date is not: "); Response.WriteSubstitution(new HttpResponseSubstitutionCallback(GetDate)); }

Když na tuto stránku nyní aplikujete cachování pomocí direktivy OutputCache, bude se při každém požadavku datum aktualizovat, protože metoda zpětného volání obchází proces ukládání do cache. Výsledek běhu stránky a její několikanásobnou aktualizaci vidíte na obrázku 11-2.

Obrázek 11-2. Injektáž dynamického obsahu do cachované stránky.

Potíž s touto technikou je v tom, že nahrazení po uložení do cache funguje na nižší úrovni než zbytek vašeho rozhraní. Když navrhujete nějakou stránku ASP.NET, tak obvykle vůbec nepoužíváte objekt Response – pracujete s webovými ovládacími prvky, které pak využívají objekt Response, aby vygenerovaly svůj obsah. Pou-

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

461

žijete-li objekt Response stejným způsobem jako v předchozím v příkladu, jednou z nevýhod je to, že přijdete o možnost umisťovat svůj obsah s ohledem na zbytek stránky. Jediné realistické řešení je obalit dynamický obsah do nějakého druhu ovládacího prvku. Až se bude tento ovládací prvek realizovat, pak teprve bude schopen zavolat Response.WriteSubstitution(). O realizaci ovládacích prvků se dozvíte více v kapitole 27.

Pokud vás mrzí, že se musíte trápit s vývojem vašeho vlastního ovládacího prvku jenom proto, abyste se dostali ke schopnosti nahrazení po uložení do cache, nedělejte to. ASP.NET totiž nabízí zkratku – obecný ovládací prvek Substitution, který pomocí právě popsané techniky udělá veškerý svůj obsah dynamickým.

Ovládací prvek Substitution je možné svázat se statickou metodou, která vrátí váš dynamický obsah stejně jako v předchozím příkladu. Vy ovšem můžete ovládací prvek Substitution umisťovat úplně stejně jako jiné ovládací prvky ASP.NET, takže váš dynamický obsah dostanete přesně tam, kde chcete, aby se objevil.

Podívejte se na ukázku, která je vlastně duplikátem jedné předchozí ukázky, ve které jsou použity značky v .aspx části stránky: Toto datum se ukládá se stránkou: <asp:Label ID="lblDate" runat="server" /><br /> Ovšem toto datum už nikoliv: <asp:Substitution ID="Substitution1" runat="server" MethodName="GetDate" />

V době návrhu stránky bohužel neuvidíte obsah ovládacího prvku Substitution.

Nezapomínejte na to, že náhrada po uložení do cache umožňuje vykonat pouze statickou metodu.

ASP.NET stále přeskakuje životní cyklus stránky, což znamená, že nevytvoří žádné objekty ovládacích prvků, a neodpálí se žádné události ovládacích prvků. Jestliže je váš dynamický obsah závislý na hodnotách jiných ovládacích prvků, budete potřebovat použít jinou techniku (jakou je třeba cachování dat), protože objekty těchto ovládacích prvků nebudou vaší statické metodě zpětného volání dostupné.

POZNÁMKA Vaše vlastní ovládací prvky mohou dle libosti volat Response.WriteSubstitution(), aby nastavily své chování týkající se ukládání do cache. Například prvek AdRotator to využívá k tomu, aby zajistil, že na stránce bude pořád střídat nějaká reklama, i když zbytek výstupu stránky se bude brát z cache.

Profily cache Jednou z nesnází spojených s cachováním výstupu je to, že je potřeba vložit do stránky instrukci – buď do .aspx části se značkami, nebo do kódu třídy. Přestože je první volba (použití OutputCache) relativně jasná, určitě se objeví starosti ohledně správy, pokud vytvoříte desítky stránek, které cachujete. Budete-li pak chtít u všech těchto stránek změnit způsob ukládání do cache (například změnit dobu trvání platnosti z 30 na 60 vteřin), budete muset modifikovat každou stránku. ASP.NET navíc bude vyžadovat překompilování těchto stránek.

ASP.NET 2.0 přichází s novou volbou, která se hodí, potřebujete-li aplikovat stejná nastavení týkající se cache na celou skupinu stránek. Tato schopnost, která se nazývá jako profily cache (cache profiles), umožňuje definovat nastavení pro cache v souboru web.config, asociovat s těmito nastaveními nějaký název, a pak prostřednictvím tohoto názvu použít tato nastavení ve více stránkách. Pak budete moci modifikovat všechny propojené stránky najednou a na jediném místě – pouze změníte profil cache v souboru web.config.

Profil cache definujete tak, že do sekce <outputCacheProfiles> přidáte značku <add> – viz ukázka. Přiřadíte v ní název a dobu trvání.

KAPITOLA 22 Autentizace Windows Formulářová autentizace je výborná, chcete-li vytvořit vlastní autentizační systém s záložní databází a vlastní přihlašovací stránkou. Co když ale vytváříte webovou aplikaci pro menší skupinu známých uživatelů, kteří už mají své uživatelské účty Windows? V podobných situacích může být vhodnější nasazení systému, který do svého fungování zapojí již existující údaje o uživatelích a členství ve skupinách.

Problém lze vyřešit pomocí autentizace Windows, při níž se srovnávají údaje o uživatelích webu s uživatelskými účty Windows, které jsou definovány na lokálním počítači nebo v jiné doméně sítě. V této kapitole se dozvíte, jak autentizaci Windows použít ve vašich webových aplikacích. Dozvíte se také, jak použít impersonalizaci (impersonation) pro dočasné převzetí cizí identity.

Představení autentizace Windows Autentizace Windows není na rozdíl od formulářové integrována v ASP.NET. Místo toho předává zodpovědnost za autentizaci IIS. Webový server IIS požádá o autentizaci prohlížeč, který poskytne přihlašovací doklady, které jsou pak mapovány na uživatelský účet Windows. Je-li uživatel autentizován úspěšně, IIS povolí žádost o webovou stránku a předá informace o uživateli a roli ASP.NET tak, že programový kód může fungovat téměř stejně, jako když pracuje s informacemi o identitě v situaci s formulářovou autentizací. Obrázek 22-1 na následující stránce názorně ukazuje celý proces.

Proč používat autentizaci Windows?

Jsou pro to tři hlavní důvody:

• • •

Velmi málo programátorské práce pro vývojáře.

Dovoluje použít existující uživatelská přihlášení.

Dovoluje použít impersonalizaci a zabezpečení Windows.

838

Kapitola 22 – Autentizace Windows

Obrázek 22-1. Autentizační proces Windows.

První důvod je zcela jednoduchý – při použití autentizace Windows je IIS a klientovi dovoleno se o autentizační proces postarat, takže nemusíte vytvářet přihlašovací stránku, kontrolovat databázi nebo psát nějaký vlastní programový kód. Windows dále podporují takové základní aspekty uživatelského účtu jako je vypršení doby platnosti hesla, uzamčení účtu nebo členství ve skupinách.

Druhý a nejdůležitější důvod pro použití autentizace Windows spočívá v tom, že vám dovoluje zapojit do práce existující účty Windows. Tento typ autentizace se standardně používá pro aplikace, v nichž uživatelé i webový server patří ke stejné lokální síti nebo intranetu. To znamená, že uživatelé mohou být autentizováni pomocí stejných přihlašovacích dokladů, které používají pro přihlašování k počítači. Největším přínosem této metody je, že lze provádět "neviditelnou" autentizaci, u které (v závislosti na použitých nastaveních a architektuře sítě) není nutná samostatná přihlašovací procedura. Prohlížeč místo ní jednoduše používá identitu aktuálně přihlášeného uživatele.

Třetím důvodem pro použití autentizace Windows je to, že dovoluje využít výhod existujících zabezpečovacích nastavení Windows. Můžete např. ovládat přístup k souborům pouhým nastavením přístupových oprávnění k souborům Windows. Je ovšem důležité si uvědomit, že tato oprávnění nemají automatický účinek. Je to proto, že vaše webová aplikace obvykle používá pevný účet (standardně je to účet ASPNET, který je definován v souboru machine.config). Tento režim lze změnit opatrným použitím autentizace Windows a impersonalizace, jak je popsáno v sekci s názvem "Impersonalizace a delegování na Windows Serveru 2003" v této kapitole.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

839

Proč nepoužívat autentizaci Windows?

Proč byste neměli používat tento způsob autentizace?

• • •

Je spjat s uživateli Windows.

Je spjat s klientskými počítači Windows.

Nenechává příliš velkou flexibilitu nebo možnost ovládání a nedá se snadno přizpůsobovat.

První problém spočívá v tom, že autentizace Windows nebude fungovat, pokud uživatelé, které autentizujete, nemají platné účty Windows. U veřejných webů tuto překážku pravděpodobně nelze vůbec odstranit. I kdyby bylo možné pro každého uživatele vytvořit účet Windows, nebylo by to nikdy tak efektivní jako databázový přístup pro větší množství uživatelů. Existuje zde také potenciální bezpečnostní riziko, protože účty uživatelů Windows mohou mít oprávnění k přístupu na počítač webového serveru nebo k jiným síťovým počítačům.

Druhý problém spočívá v tom, že některé autentizační metody používané IIS od uživatelů vyžadují, aby měli na počítači kompatibilní software, což omezuje schopnosti autentizace Windows u těch, kteří nemají operační systém od Microsoftu, nebo nepoužívají Internet Explorer.

A posledním velkým problémem je to, že autentizace Windows nedává žádné možnosti pro řízení autentizačního procesu. Nelze tedy jednoduše programově přidávat, odstraňovat a ovládat informace spjaté s účtem Windows nebo ukládat jiné informace specifické pro jednotlivé uživatele společně s přihlašovacími doklady.

Jak jste se dočetli v předchozí kapitole, všechny tyto aspekty se dají snadno začlenit do formulářové autentizace, ale v autentizaci Windows nehrají žádnou roli.

Mechanismy autentizace Windows Pokud implementujete autentizaci Windows, IIS použije jednu ze tří autentizačních strategií pro autentizaci každého přijatého požadavku.

•

Základní autentizace. Uživatelské jméno a heslo je předáváno jako prostý text. Základní autentizace je jako jediná autentizační metoda podporována všemi prohlížeči jako součást standardu HTML.

•

Digestní autentizace. Není přenášeno ani uživatelské jméno ani heslo. Místo toho se posílá hašovaná forma těchto údajů, která je z kryptografického hlediska bezpečná.

•

Integrovaná autentizace Windows. Není přenášeno ani uživatelské jméno ani heslo. Místo toho je údaj o identitě uživatele, který se právě přihlásil k Windows, automaticky předáván ve formě tokenu.

Je to jediný typ autentizace, který se uskutečňuje zcela transparentně (bez zásahu uživatele).

Následující sekce této kapitoly probírají tyto tři uvedené možnosti.

POZNÁMKA Pro autentizaci Windows existují i méně používané protokoly. Je to např. autentizace založená na certifikátu. Pokud zvolíte tento typ autentizace, musíte všem klientům rozeslat digitální certifikát a každý certifikát namapovat na příslušný účet Windows. U této metody se bohužel příliš často objevují problémy s administrací a dislokací. IIS 6 navíc podporuje pokročilou souhrnnou autentizaci (funguje v podstatě stejně jako digestní autentizace, ale hesla ukládá bezpečněji) a passportovou autentizaci umožňující uživateli se přihlásit k passportovému účtu, který se na uživatelský účet Windows mapuje.

840

Kapitola 22 – Autentizace Windows

Základní autentizace Nejpodporovanějším autentizačním protokolem je základní autentizace. Podporují ji téměř všechny webové prohlížeče. Pokud web vyžaduje autorizaci klienta pomocí základní autentizace, prohlížeč zobrazí přihlašovací dialog pro zadání uživatelského jména a hesla, který je podobný dialogu na obrázku 22-2.

Obrázek 22-2. Přihlašovací dialog pro základní autentizaci.

Poté, co uživatel poskytne tyto údaje, jsou samotná data přenesena na webový server (v tomto případě localhost). Jakmile IIS obdrží autentizační data, pokusí se uživatele autentizovat ve spolupráci s odpovídajícím účtem Windows.

Největším omezením základní autentizace je její nedostatečné zabezpečení, alespoň co se týče jí samotné.

Přihlašovací doklady, které jsou reprezentovány uživatelským jménem a heslem, a které jsou získány pomocí základní autentizace, jsou mezi klientem a serverem přenášeny jako prostý text. Samotná data jsou zakódována (nikoliv šifrována) do řetězce typu Base64, který různí slídilové dokáží velmi snadno přečíst. Z tohoto důvodu byste měli základní autentizaci používat jen tehdy, když není potřeba přihlašovací doklady uživatele chránit, nebo jenom ve spolupráci s nějakým šifrovacím protokolem HTTP jako je např. SSL. Takto budou data, která jsou jinak snadno dostupná pro jakoukoliv síťovou slídicí utilitu, zašifrována pomocí komplexního algoritmu. (Více informací o SSL najdeme v kapitole 18.)

Digestní autentizace Tento typ autentizace (stejně jako základní autentizace) vyžaduje od uživatele, aby zadal informace do přihlašovacího dialogového boxu, který je zobrazen prohlížečem. Na rozdíl od základní autentizace však digestní autentizace předává místo hesla samotného jeho hašovanou formu. (Anglické slovo digest je synonymem slova haš – odtud pochází název tohoto autentizačního schématu.) Samotné heslo se v textové podobě nikdy po síti neposílá, protože se posílá jeho hašovaná forma, což zabraňuje zcizení hesla i přes fakt, že není použito SSL. Proces autentizace uživatele pomocí souhrnné metody funguje takto: 1.

Neautentizovaný klient požaduje webovou stránku s omezeným přístupem.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

841

2.

Server odpoví odezvou HTTP 401. Tato odezva zahrnuje příležitostnou hodnotu (nonce value), což je náhodně vygenerovaná série bitů. Server zajišťuje, že každá příležitostná hodnota bude jedinečná, předtím než ji použije.

3.

Klient použije pro vytvoření haše příležitostnou hodnotu, heslo, uživatelské jméno a některé další hodnoty. Hodnota tohoto haše, tzv. digest, je poslána zpátky na server společně s uživatelským jménem ve formě prostého textu.

4.

Server použije příležitostnou hodnotu, heslo uložené pro uživatelské jméno a ostatní hodnoty pro vytvoření haše. Tento haš pak porovná s hašem získaným od klienta. Pokud obě hašované hodnoty souhlasí, je autentizace úspěšná.

Digest není útočníkovi příliš platný, protože příležitostná hodnota se mění s každým autentizačním požadavkem. Z digestu se původní heslo extrahovat nedá. Protože digest obsahuje příležitostnou hodnotu, nemůže být použit pro opakovaný útok (replay attacks), kdy se útočník pokouší získat přístup ke chráněným zdrojům tak, že použije dříve zachycený digest.

Teoreticky je digestní autentizace standardem a webové servery a prohlížeče by měly být schopny ji používat pro výměnu autentizačních informací. Firma Microsoft bohužel interpretuje část specifikace digestní autentizace trochu jiným způsobem než ostatní organizace, jako např. Apache Foundation (webový soubor Apache) a projekt Mozilla (webový prohlížeč Mozilla). Důsledkem je, že digestní autentizace IIS v současnosti funguje pouze v Internet Exploreru 5.0 a vyšších verzích.

Dalším omezením digestní autentizace v IIS je to, že funguje pouze tehdy, když autentizovaný virtuální adresář běží pod doménovým řadičem Windows Active Directory.

Integrovaná autentizace Windows Tato metoda je nejvhodnějším autentizačním standardem pro intranetové aplikace založené na WAN nebo LAN, neboť autentizaci vykonává bez toho, aby se vyžadovala interakce s klientem. Požádá-li IIS klienta, aby se autentizoval, prohlížeč pošle token reprezentující uživatelský účet Windows aktuálního uživatele. Pokud webový server při autentizaci pomocí těchto údajů neuspěje, objeví se dialogový box, kam může uživatel zadat jiné uživatelské jméno a heslo.

Integrovaná autentizace Windows může fungovat jen tehdy, když jsou klient a webový server ve stejné lokální síti nebo intranetu, neboť tato metoda de facto nepřenáší údaje obsahující uživatelská jména a hesla. Místo toho pracuje v koordinaci s doménovým serverem nebo instancí Active Directory, kde proběhlo přihlášení, přičemž přikáže příslušnému počítači, aby na webový server poslal autentizační údaje.

Jako protokol je pro přenášení autentizačních údajů použita buď autentizace NTLM (NT LAN Manager), nebo Kerberos 5 – závisí to na verzi operačního systému klienta a serveru. Pokud na obou běží Windows 2000 nebo vyšší, a oba stroje pracují v doméně Active Directory, je jako autentizační protokol použit Kerberos, jinak to bude autentizace NTLM. Oba protokoly jsou extrémě zabezpečené (Kerberos je z aktuálně dostupných protokolů ten nejbezpečnější), nicméně, mají nějaká omezení. Integrovaná autentizace v zásadě pracuje jenom v Internet Exploreru 2.0 a vyšších (integrovaná autentizace Windows není podporována v ne-internetových klientech Exploreru). Kerberos samozřejmě funguje jenom na počítačích, na kterých běží Windows 2000 nebo vyšší verze, a ani jeden z protokolů nemůže pracovat přes proxy server. Kerberos navíc vyžaduje, aby byly otevřeny některé další porty na firewallech. V této kapitole se dále dozvíte základní věci o autentizačních protokolech používaných pro integrovanou autentizaci Windows, což vám pomůže lépe pochopit jednotlivé konfigurační kroky (zejména impersonalizaci a delegování).

842

Kapitola 22 – Autentizace Windows

Autentizace typu NT LAN Manager Autentizace NTLM je integrována v operačním systému Windows od okamžiku, kdy byla do něj zahrnuta podpora sítí. NTLM autentizuje klienty pomocí mechanismu výzva/odezva, který je založen na trojí výměně mezi klientem a serverem. Všechny procesy, o nichž se dozvíte v této sekci, se odehrávají v operačním systému zcela automaticky. Přirozeně – všechno bude fungovat pouze za předpokladu, kdy klient i server používají operační systém Windows.

Klient zahajuje komunikaci vysláním zprávy na server, což signalizuje, že klient chce se serverem komunikovat. Server vygeneruje 64bitovou náhodnou hodnotu nazvanou jako příležitostná. Server na požadavek klienta odpovídá tím, že příležitostnou hodnotu navrací. Této odezvě se říká výzva. Nyní operační systém klienta požaduje od uživatele uživatelské jméno a heslo. Heslo v hašované formě – nazývané jako master-key – bude následně použito pro zašifrování příležitostné hodnoty. Klient posílá serveru svoji odezvu společně s uživatelským jménem a zašifrovanou příležitostnou hodnotou (čímž se dokončuje mechanismus výzva/odezva).

Server musí nyní ověřit platnost vrácené příležitostné hodnoty. Podle toho, zdali se jedná lokálního uživatel nebo uživatele v rámci domény, se validace uskutečňuje lokálně nebo vzdáleně na doménovém řadiči. V obou případech je master-key uživatele, tedy hašovaná verze hesla, získáván z databáze zabezpečených účtů. S využitím master-key se příležitostná hodnota ve formátu prostého textu zašifruje na serveru ještě jednou (server pochopitelně cachuje příležitostnou hodnotu v textové podobě předtím, než pošle data klientovi). Pokud opětovně vytvořená šifrovaná verze příležitostné hodnoty souhlasí se šifrovanou verzí vrácenou z klienta, je autentizace úspěšná, a pro uživatele je na serveru vytvořena přihlašovací relace. Obrázek 22-3 ukazuje průběh tohoto procesu.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

843

Obrázek 22-3. Letmý pohled na NTLM. Z popisu je jasně vidět, že heslo se nikdy nepřenáší po lince. Dokonce se ani nepředává hašovaná verze hesla, což bezpečnost NTLM značně zvyšuje. Existuje ale ještě bezpečnější protokol s dalšími možnostmi, jak uvidíte v další sekci.

Autentizace pomocí Kerberos: krátké představení V současné době je Kerberos 5 nejbezpečnějším dostupným autentizačním protokolem. Je to veřejně známý standard, který byl vytvořen organizací IETF (Internet Engineering Task Force), a který implementuje autentizační protokol založený na autentizačních lístcích. V operačním systému Windows je Kerberos k dispozici od verze Windows 2000. Pokud aktivujete integrovanou autentizaci Windows, Kerberos bude automaticky použit za splnění těchto podmínek:

• •

Na klientovi a serveru běží Windows 2000 nebo vyšší.

V síti je dostupná doména Active Directory s řadičem primární domény (který se automaticky přebírá roli tzv. distribučního centra klíčů)

Ve všech ostatních případech použije Windows jako autentizační protokol NTLM. Ačkoli detailní popis protokolu Kerberos by byl na samostatnou knihu, v této kapitole se alespoň dozvíte o základních konceptech. Ty vám pomohou porozumět nejenom nezbytným úkolům při konfiguraci, ale také tomu, kdy budou v činnosti

844

Kapitola 22 – Autentizace Windows

jednotlivé funkce. Jedním z největších rozdílů mezi NTLM a Kerberos je například to, že Kerberos podporuje impersonalizaci a delegování, zatímco NTLM jenom impersonalizaci.

Delegování je v zásadě založeno na stejném konceptu jako impersonalizace. Jde v něm pouze o akce vykonávané v zastoupení za identitu klienta. Zatímco impersonalizace funguje v rámci jednoho počítače, delegování pracuje napříč celou sítí. To znamená, že autentizační lístek původní identity klienta může být předán jinému serveru v síti, pokud má k tomu původní server příslušná oprávnění. O impersonalizaci a delegování se více dozvíte později v této kapitole. Prozatím je důležité vědět, že Kerberos podporuje jak impersonalizaci, tak i delegování, zatímco NTLM a ostatní autentizační techniky Windows (jako základní nebo digestní autentizace) podporují pouze impersonalizaci.

Klíčovou komponentou systému Kerberos je KDC (key distribution center, centrum distribuce klíčů), které zodpovídá za generování lístků a správu přihlašovacích dokladů. Ve světě Windows hraje roli KDC primární doménový řadič Active Directory. Každý aktér (klient a server) musí KDC důvěřovat. Spravuje totiž všechny uživatelské a počítačové účty a generuje autentizační a relační lístky pro komunikační relace mezi jednotlivými počítači v rámci domény. To je další velký rozdíl, který najdeme při srovnávání Kerberos a NTLM – NTLM pracuje v situacích pracovních skupin bez centrální správy, Kerberos ovšem pro vydávání všech typů lístků centrální správu vyžaduje. Pro nasazení protokolu Kerberos je požadováno spojení s doménovým řadičem Active Directory. Obrázek 22-4 ukazuje postup autentizace uživatele a ustavení relace mezi klientem a jednoduchým členským serverem v rámci domény.

Každý uživatelský autentizační proces začíná zasláním požadavku autentizační službě, která běží na KDC. Tento požadavek obsahuje uživatelské jméno uživatele, který má být autentizován. KDC získá uživatelský master-key z databáze zabezpečených účtů. Opět to je hašovaná verze uživatelského hesla. Poté je vytvořen TGT (ticket-granting ticket, povolovací lístek). Tento lístek obsahuje klíč relace pro relaci uživatele a datum a čas vypršení platnosti. Než je lístek vrácen klientovi, server jej za použití uživatelského master-key zašifruje.

Pouze se správným heslem vloženým uživatelem může operační systém klienta vytvořit správný master-key (haš) pro úspěšné dešifrování TGT požadavku získaného ze serveru. Pokud je dešifrování TGT na klientovi úspěšné, je uživatel úspěšně autentizován. Klient pak nakonec TGT lokálně cachuje.

Pokud chce klient komunikovat s jiným členským serverem v rámci sítě, musí požádat KDC o relační lístek.

Pro tyto účely posílá lokálně cachovaný TGT na tzv. povolovací službu, která běží na KDC. Tato služba ověřuje platnost TGT. Pokud je TGT stále platný (nevypršela jeho doba platnosti, nikdo s ním nemanipuloval apod.), služba vygeneruje klíč relace pro komunikační relaci mezi klientem a členským serverem. Relační klíč je pomocí master-key klienta zašifrován. Relační klíč je navíc začleněn do ST (session ticket, lístek relace), který obsahuje dodatečnou informaci pro server o době platnosti. Relační lístek je zašifrován pomocí master-key členského serveru. Zašifrovaný klíč relace i zašifrovaný lístek relace jsou přeposlány klientovi. Klient dešifruje klíč relace a přepošle lístek relace serveru. KDC samozřejmě dobře zná jak klienta, tak i server, protože oba byly v minulosti přidány do domény (přidání počítače do domény znamená ustavení spolehlivého vztahu mezi počítačem a KDC). KDC proto zná jak master-key klienta, tak i master-key serveru.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

845

Obrázek 22-4. Autentizace pomocí protokolu Kerberos a lístky.

Pokud server dešifruje relační lístek od klienta a ověření jeho platnosti je úspěšné, je ustanovena komunikační relace. Klient i server použijí pro šifrování komunikace už vytvořený klíč relace. Jakmile vyprší platnost lístku relace, celá operace se opakuje.

Každý lístek – relační i povolovací – mají jisté schopnosti. Mohou například na serveru napodobit uživatele klienta nebo delegovat identitu klienta na jiný server. Pokud klient a KDC tyto schopnosti nezačlení do lístku, nebudou funkční. Proto klient a server potřebují dodatečná oprávnění, jak se dočtete v sekci Impersonalizace dále v této kapitole.

Základní koncepty NTLM a Kerberos budeme dále rozebírat proto, abyste pochopili nezbytné konfigurační kroky zajišťující funkčnost impersonalizaci a delegování. Pro většinu situací platí, že pokud nefunguje něco, co se týká impersonalizace nebo delegování, je to proto, že je chyba v konfiguraci doménového řadiče nebo KDC (používáte-li Active Directory), nebo proto, že datum vypršení platnosti lístku není adekvátně nastaveno (doba platnosti by neměla být nastavena jako příliš dlouhá, ale ani jako příliš krátká). Třebaže detailní rozbor diskutovaných témat by si vyžádal další knihu, tento přehled vám pomůže pochopit, jak protokol funguje a jaké jsou požadavky pro různé scénáře použití.

KAPITOLA 32 Tvorba webových služeb Už léta bojují softwaroví vývojáři a architekti o vytvoření softwarových komponent, které by mohly být vzdáleně zavolány prostřednictvím lokální sítě a Internetu. Během tohoto procesu bylo vytvořeno několik nových technologií a několik komplikovaných proprietárních řešení. Ačkoliv některé z těchto technologií byly docela úspěšné (pokud jde o spouštění back-end systémů v interních sítích), ani jedné z nich se nepodařilo zvládnout složité problémy spojené s Internetem, který představuje širokou, a někdy nespolehlivou síť počítačů, na nichž běží všechny možné typy hardware a operačních systémů.

Zde přichází na scénu webové služby XML (XML web services). Pokud chcete komunikovat s nějakou webovou službou, stačí poslat prostřednictvím HTTP příslušnou zprávu XML. Protože každé zařízení, které je určeno pro Internet podporuje HTTP protokol, a protože každý programovací jazyk umožňuje přistupovat ke XML parseru, existují určitá omezení ohledně typů aplikací, které mohou používat webové služby. V podstatě většina programovacích prostředí obsahuje sadu nástrojů vyšší úrovně, díky kterým je komunikace s webovou službou stejně snadná jako volání lokální funkce.

Tato kapitola přináší nejenom přehled webových služeb, ale také problémů, které tyto služby řeší. Pokud je tato problematika pro vás zcela nová, naučíte se, jak vytvářet a používat webové služby v ASP.NET. Zatím se však nebudete detailněji zabývat nižší úrovní – základními protokoly. Místo toho začnete webovou službu rovnou používat, přičemž v další kapitole se naučíte, jak ji rozšířit.

1204

Kapitola 32 – Tvorba webových služeb

ZMĚNY TÝKAJÍCÍ SE WEBOVÝCH SLUŽEB V .NET 2.0 Pokud jste již programovali s webovými službami v .NET 1.x, pravděpodobně vás zajímá, co všechno se v změnilo v .NET 2.0. Z praktického hlediska je zde překvapivě málo nových věcí, výchozí infrastruktura je v podstatě úplně stejná. Najdete zde však spoustu užitečných zlepšení, z nichž mnoho se týká fungování webových služeb s komplexními typy (což jsou vlastní třídy dat, které se používají pro zasílání nebo získávání informací pro webovou metodu). Najdete zde popsány všechny tyto změny:

•

Podpora pro vlastnosti procedur. Pokud máte webovou službu, která používá vlastní typ, .NET vytvoří kopii této třídy u klienta. V .NET 1.x je tato automaticky generovaná třída sestavena z veřejných vlastností. V .NET 2.0 se místo toho používají vlastnosti procedur. Tato malá změna sice neovlivní způsob fungování webové služby, nicméně vám umožní použít tuto třídu ve scénářích vázání dat.

•

Sdílení typů. .NET nyní rozeznává, pokud dvě webové služby používají stejný komplexní typ a generuje pouze jednu třídu na straně klienta. Nejlepší na tom je, že díky tomu, že obě třídy používají stejné typy, můžete snadno z jedné webové služby získat nějaký objekt a přímo jej poslat k jiné webové službě.

•

Vlastní serializace. Nyní můžete zapojit vaše vlastní třídy do procesu serializace tak, aby mohly kompletně řídit svoji vlastní reprezentaci v XML. Ačkoli jste serializaci mohli provádět i v ASP.NET 1.x, nebyla tato serializace zdokumentována a dostatečně podporována.

•

Bohaté objekty. Potřebujete si vyměňovat komplexní objekty společně s metodami a konstruktory?

Nyní je to možné, pokud vytvoříte novou komponentu nazývanou jako importér schématu (schema importer) . Importér schématu ověřuje schéma webové služby a sděluje třídě, jaké typy by měla použít.

•

Contract-first vývoj. Nyní si můžete vybudovat webovou službu .NET, která bude srovnatelná s již existujícím WSDL.

Všechna tato zlepšení podrobně popisuje kapitola 33.

Mnoho dramatických změn je ovšem stále ještě před vámi. Vývojáři Microsoftu dokončují Indigo, což je nový model pro distribuci zpráv, který obsahuje funkcionalitu webové služby a další technologie .NET, jako je například vzdálený přístup. Ačkoli bude určitě poskytnut přirozený způsob, jak přejít od webové služby ASP. NET k modelu Indigo, mnoho detailů implementace bude změněno. Indigo není součástí .NET 2.0, nýbrž by mělo být dodáváno s další verzí Windows (která nebude k dispozici dříve než koncem roku 2006). Microsoft však naznačil, že ještě předtím by mohl vydat sadu nástrojů Indigo určenou pro jiné verze Windows. Další informace získáte ve vývojářském centru Microsoft Indigo na adrese http://msdn.microsoft.com/ Longhorn/understanding/pillars/Indigo.

Přehled webových služeb Zatímco HTML stránky (nebo HTML výstup vygenerovaný webovými formuláři ASP.NET) by měly být používány koncovými uživateli, webové služby jsou používány jinými aplikacemi. Jsou to části obchodní logiky, ke kterým se lze dostat přes Internet. Například stránky internetového obchodu můžou využívat webovou službu nějaké poštovní společnosti pro výpočet ceny za dopravu zásilky. Stránka se zpravodajstvím může získávat nadpisy a články od externích dodavatelů zpráv a zobrazovat je v reálném čase na svých vlastních stránkách. Web může dokonce poskytovat aktuální hodnoty akcií, které jsou získávány ze specializovaných

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

1205

finančních nebo investičních stránek. To ovšem není žádná vzdálená budoucnost. Všechny tyto scénáře na webu už rutinně fungují a největší internetové společnosti, jako jsou Amazon, Google a eBay nabízejí vývojářům k použití své vlastní webové služby.

Pomocí webových služeb můžete prostřednictvím několika řádek kódu použít obchodní logiku někoho jiného, aniž byste ji museli vytvářet od úplného začátku. Tato technika je podobná technice, kterou používají programátoři v případě knihoven API, tříd a komponent. Hlavní rozdíl je v tom, že webové služby mohou být umístěny na vzdáleném serveru a zpravovány jinou společností.

Historie webových služeb Ačkoliv webové služby představují novou technologii, můžete hodně pochopit, pokud znáte jejich nedávnou historii. Dvě z největších změny v oblasti vývoje softwaru, které proběhly během několika posledních dekád, se týkaly vývoje objektově orientovaného programování a technologie založené na komponentách.

Objektově orientované programování se připojilo k hlavnímu programovacímu proudu někdy v osmdesátých letech minulého století. Mnozí lidé v objektově orientovaném programování viděli řešení softwarové krize, která vyplývala z narůstající složitosti a velikosti softwarových aplikací. Mnoho projektů se opozdilo a překročilo svůj rozpočet, přičemž výsledný produkt byl často nespolehlivý. Objektově orientovaný kód sliboval začlenění objektů do kódu, díky čemuž mohli vývojáři vytvářet komponenty, které byly opakovaně použitelné, rozšiřitelné a snadno udržovatelné.

V devadesátých letech minulého století se objevila technologie komponent, která umožnila budovat aplikace sestavováním komponent. Technologie založená na komponentech je skutečným rozšířením objektově orientovaných principů za hranice libovolného jazyka, takže se stává jádrem infrastruktury, které může kdokoliv použít. Zatímco objektově orientovaný jazyk umožňoval vývojářům opakovaně používat objekty ve svých aplikacích, technologie založená na komponentách jim umožňovala snadno sdílet zkompilované objekty mezi aplikacemi. Vznikly dvě dominantní technologie založené na komponentách – COM (Component Object Model) a CORBA (Common Object Request Broker Architecture). Od té doby se objevily další technologie založené na komponentách (jako například JavaBeans a .NET), nicméně jsou navrženy jako proprietární řešení pro konkrétní programovací prostředí.

Krátce poté, co byly COM a CORBA vytvořeny, byly tyto standardy použity u distribuovaných komponent tak, aby aplikace mohla pracovat s objekty umístěnými v různých počítačích zapojených do sítě. Ačkoli COM i CORBA jsou po technické stránce velice sofistikované, je často velmi obtížné je nastavit a podporovat v prostředí lokální sítě, nehledě na fakt, že nemohou fungovat společně. S objevením Internetu se pak logicky objevil dramatický nárůst dalších problémů. I přesto všechno je vývojáři začali používat při vytváření distribuovaných aplikací, tzn. WAN aplikací (Wide Area Networks), které se ovšem velmi pomalu rozšiřovaly, a které také byly méně spolehlivé. Protože technologie COM i CORBA jsou velice komplexní a současně proprietární, ani jedna z nich se v tomto prostředí neprosadila natolik, aby se to dalo považovat za úspěch.

Webové služby jsou novou technologií, která má za cíl vyřešit tyto problémy rozšířením technologie objektů a komponent do webového prostředí. Webová služba je v zásadě jednotkou aplikační logiky (komponentou), která může být vzdáleně zavolána přes Internet. Očekávání vkládaná do webových služeb se v mnohém shodují s očekáváními vkládanými do technologie komponent, přičemž jejich cílem je usnadnit sestavování aplikací pomocí hotové aplikační logiky, sdílet funkcionalitu mezi partnery a vytvářet mnohem modulárnější aplikace. Na rozdíl od dřívějších technologií založených na komponentách jsou webové služby navrženy výhradně pro tento účel. To znamená, že jako vývojáři v .NET budete stále používat .NET model komponent, pomocí kterého budete schopni sdílet zkompilované assembly mezi jednotlivými aplikacemi .NET. Pokud

1206

Kapitola 32 – Tvorba webových služeb

však budete chtít sdílet funkcionalitu mezi aplikacemi, které běží na různých platformách, a které jsou poskytovány různými společnostmi, budou pro vás webové služby naprosto ideálním řešením.

Webové služby také kladou mnohem větší důraz na součinnost (interoperability). Všechny platformy pro vývoj softwaru, které umožňují programátorům vytvářet webové služby, používají jako základní kámen otevřené standardy, které jsou založeny na XML. Tím je zajištěno, že pomocí .NET můžete vytvořit nějakou webovou službu a následně ji zavolat z nějakého klienta založeného na Javě, nebo vytvořit webovou službu v Javě, a tu následně zavolat z .NET aplikace.

POZNÁMKA Webové služby nejsou omezeny pouze na .NET Framework. Standardy webových služeb byly specifikovány ještě před uvedením platformy .NET, a jsou používány a podporovány i dalšími výrobci softwaru. .NET Framework je ovšem speciálním případem, protože v sobě ukrývá veškerý propojovací kód, což vám usnadní nejenom zprovoznění vašich webových služeb přes internet, ale také vám to usnadní přístup k webovým službám, které poskytují jiné společnosti. Jak dále uvidíte, nemusíte znát XML a SOAP do naprostých detailů, abyste mohli úspěšně budovat webové služby, ačkoliv je pravda, že určitá úroveň znalostí vám rozhodně neuškodí. ASP.NET provádí abstrakci podrobnosti a vytváří obalové třídy, které vystavují jednoduchý, objektově orientovaný, model takovým způsobem, aby bylo snadné posílat, získávat a interpretovat zprávy SOAP.

Distribuované výpočty a webové služby Abyste zcela pochopili důležitost webových služeb, musíte porozumět požadavkům distribuovaných výpočtů.

Distribuované výpočty představují rozdělení aplikační logiky do jednotek, které jsou vykonávány na dvou nebo více počítačích v síti. Myšlenka distribuovaných výpočtů se zrodila už dříve, přičemž pro distribuované a současně opakované použití aplikační logiky bylo vyvinuto mnoho komunikačních technologií. Použití distribuované aplikační logiky má mnoho výhod. Zde jsou uvedeny pouze nejdůležitější výhody takového přístupu:

•

Vysoká rozšiřitelnost. Prostřednictvím distribuované aplikační logiky je zátěž rozložena na více počítačů. To sice nezlepší výkon dané aplikace u jednotlivých uživatelů (v podstatě jej může o něco snížit), nicméně to prakticky vždy zvýší rozšiřitelnost – tím se dosáhne toho, aby aplikace současně mohla sloužit podstatně většímu počtu uživatelů.

•

Snadné rozmístění. Části distribuované aplikace můžou být upgradovány, aniž by bylo potřeba upgradovat celou aplikaci. Centrálně umístěná komponenta může být aktualizována, aniž by bylo nutné aktualizovat stovky (nebo dokonce tisíce) klientů.

•

Vylepšená bezpečnost. Distribuované aplikace často přesahují hranice společnosti či organizace.

Můžete například používat distribuované komponenty, které vašemu obchodnímu partnerovi umožní získat katalog produktů vaší společnosti. Nebylo by ovšem bezpečné nechat vašeho obchodního partnera, aby se přímo napojil do databáze vaší společnosti. Místo toho musí obchodní partner použít komponentu, která běží na vašich serverech, a kterou máte pod vlastní kontrolou, a kterou můžete v případě potřeby odpovídajícím způsobem omezit.

Internet zvýšil důležitost a použitelnost distribuovaných výpočtů. Jednoduchost a všudypřítomnost Internetu z něj dělá logickou volbu při výběru základního kamene distribuovaných aplikací.

Před objevením webových služeb byly dominantní protokoly COM (při použití v síti nazývaný jako DCOM – Distributed COM) a CORBA. Ačkoli CORBA a DCOM mají mnoho společného, liší se v několika detailech, z čehož vyplývá, že je velmi obtížné dosáhnout vzájemné spolupráce těchto dvou protokolů. Tabulka 32-1

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

1207

uvádí přehled podobností a rozdílů mezi CORBA, DCOM a webovou službou. V tabulce také najdete velké množství zkratek.

Tabulka 32-1. Srovnání jednotlivých distribuovaných technologií.

Charakteristika

CORBA

DCOM

Webová služba

Mechanismus RPC (vzdálené volání procedury)

IIOP (Internet Inter-ORB Protocol)

DCE-RPC (Distributed Computing Environment Remote Procedure Call)

HTTP (Hypertext Transfer Protocol)

Kódování

CDR (Common Data Representation)

NDR (Network Data Representation)

XML (Extensible Markup Language)

Popis rozhraní

IDL (Interface Definition Language)

IDL (Interface Definition Language)

WSDL (Web Service Description Language)

Zpřístupnění

Služba pojmenování (Naming service) a obchodování (trading service)

Registr

UDDI (Universal Description, Discovery, and Integration)

Přívětivost k firewallu?

Ne

Ne

Ano

Složitost protokolů

Vysoká

Vysoká

Nízká

Použití mezi platformamy?

Částečně

Ne

Ano

Protokoly CORBA i COM umožňují vyvolat vzdálené objekty. CORBA používá standard pojmenovaný jako IIOP (Internet Inter-ORB Protocol), DCOM používá variantu standardu s názvem DCERPC (Distributed Computing Environment Remote Procedure Call). Kódování dat v CORBA je založeno na formátu s názvem CDR (Common Data Representation). V DCOM je kódování dat založeno na podobném, ale nekompatibilním formátu s názvem NDR (Network Data Representation). Tyto vrstvy standardů významně zvyšují složitost těchto protokolů.

Existují také rozdíly mezi jazyky, které oba protokoly podporují. Protokol DCOM podporuje širokou škálu jazyků (C++, Visual Basic atd.), nicméně byl hlavně používán v operačních systémech Microsoftu. Protokol CORBA také podporoval různé platformy, byl však spojen především s aplikacemi založenými na Javě. Výsledkem bylo, že vývojáři měli k dispozici dvě platformy, které byly technicky schopny podporovat systémy distribuovaných objektů, nicméně však nemohly spolupracovat společně.

Problémy spojené s technologiemi distribuovaných komponent Součinnost představuje pouze část problémů spojených s protokoly CORBA a DCOM. Tyto protokoly se potýkají také s dalšími technickými potížemi – oba byly vyvinuty dříve než Internet a jako takové nejsou navrženy tak, aby počítaly s volně propojenou, a někdy nespolehlivou a velice zatíženou sítí. Oba tyto protokoly jsou orientované na spojení. To znamená, že DCOM klient udržuje spojení s DCOM serverem, aby mohl realizovat vícenásobná volání. DCOM komponenta na straně serveru si může v paměti uchovávat informace o klientovi. Tím vzniká bohatý a flexibilní programovací model, nicméně to však není vhodný způsob pro navrhování rozsáhlých aplikací, které používají bezstavové protokoly Internetu. Pokud klient jednoduše

1208

Kapitola 32 – Tvorba webových služeb

zmizí, aniž by řádně ukončil spojení, je zbytečně plýtváno důležitými zdroji. A podobně v případě, kdy se najednou pokouší připojit tisíce uživatelů, je server snadno zahlcen a rychle vyčerpá svou paměť nebo kapacitu spojení.

Další problém je vtom, že oba protokoly jsou mimořádně komplexní. Kombinují v sobě technologii distribuovaného objektu s bezpečnostními funkcemi sítě a řízením životního cyklu. Používání webových služeb je ovšem mnohem jednodušší, protože nejsou natolik sofistikované. Neznamená to však, že nemůžete vytvořit bezpečnou webovou službu. Při vytváření takové bezpečné webové služby se však musíte opřít o nějaký další standard, například o SSL (implementované webovým serverem) nebo WSSecurity a XML Encryption (které jsou implementovány programovacím rámcem).

POZNÁMKA Existuje zde nebezpečí, že vývojáři budou zaplaveni vznikajícími standardy, které nejsou potřebné pro základní webové služby, nýbrž pro sofistikované aplikace webové služby. Tento model však ještě pořád představuje nejlepší kompromis mezi složitostí a jednoduchostí. Výhodou je, že architekti mohou vyvíjet inovace webových služeb (jako je například podpora transakcí), aniž by byli nuceni přistupovat ke kompromisům na základní úrovni součinnosti, kterou poskytují základní standardy webových služeb.

Výhody webových služeb Webové služby jsou zajímavé z několika hledisek. Z technologického hlediska se webové služby snaží vyřešit problémy těsně spojených technologií, jako jsou například CORBA a DCOM. Jsou to problémy jako je například průchod přes firewally, zpracování složitých transportních protokolů nižší úrovně a integrace různorodých platforem. Webové služby jsou také zajímavé z organizačního a ekonomického hlediska, protože otevírají dveře novým způsobům obchodování a integraci systémů mezi jednotlivými organizacemi.

DCOM a CORBA jsou vhodné pro budování podnikových aplikací, kde software běží na stejné platformě a podobně spravované lokální síti. Nejsou však vhodné pro vytváření aplikací, které propojují jednotlivé platformy, komunikují přes Internet, a které potřebují Internet pro dosazení větší rozšiřitelnosti. Pro tyto účely jednoduše nejsou určeny.

Zde tedy přicházejí webové služby, které představují další logický krok ve vývoji distribuovaných technologií založených na komponentách. Jejich největší výhody jsou následující:

•

Webové služby jsou jednoduché. Jejich jednoduchost spočívá v tom, že mohou být snadno podporovány širokou škálou platforem.

•

Webové služby jsou volně spojeny. Webová služba může rozšířit svoje rozhraní a přidat nové metody, aniž by to jakkoliv ovlivnilo klienty (pokud ovšem webová služba poskytuje staré metody a parametry).

•

Webové služby jsou bezstavové. Klient vznese vůči webové službě požadavek, ta mu vrátí výsledek a spojení je ukončeno. Neexistuje permanentní spojení. To umožňuje se snadno přizpůsobit mnoha klientům a k poskytování webových služeb využívat serverovou farmu. Výchozí HTTP protokol, který je používán webovými službami, je rovněž bezstavový. Je samozřejmě možné poskytnout nějaký stav pomocí dodatečných technik, jako jsou například techniky používané u webových stránek ASP. NET včetně cookies. Tyto techniky však nejsou obecně standardizovány.

•

Webové služby jsou přívětivé k firewallu. Firewally mohou pro technologie distribuovaných objektů představovat problém. Jediné, co přes firewally prakticky vždy projde, je HTTP provoz na portech

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

1209

80 a 443. Protože webové služby zcela standardně používají HTTP protokol, mohou bez problémů procházet přes firewally, aniž by k tomu potřebovaly změnit nějaké nastavení firewallu.

POZNÁMKA Firewall je ovšem možné použít k blokování přenosu zpráv SOAP. Je to možné díky tomu, že HTTP záhlaví zprávy nějaké webové služby rozpoznává zprávy SOAP a administrátor může firewall nakonfigurovat tak, aby zablokoval přenos těchto zpráv. Pro konkrétní scénáře typu "obchodník-s-obchodníkem" je možné firewall nastavit tak, aby byl povolen přenos zpráv SOAP pouze z vybraných IP adres.

Je samozřejmé, že jednoduchost webových služeb si vybírá svou daň. Webové služby nemají všechny funkce mnohem komplexnějších technologií distribuovaných komponent. Nenajdete zde například podporu oboustranné komunikace, což značí, že webový server nemůže zpětně zavolat klienta poté, co se klient odpojil.

V tomto ohledu jsou těsně spojené protokoly jako například DCOM a CORBA mnohem výkonnější než webové služby. .NET Framework ovšem nabízí novou technologii nazvanou jako remoting (vzdálené volání), která je ideální pro komunikaci mezi distribuovanými .NET aplikacemi a interní sítí. Remoting je následovníkem DCOM na platformě .NET.

KDY POUŽÍT WEBOVÉ SLUŽBY Microsoft doporučuje se zamyslet nad následujícími příklady, pokud z nějakého důvodu nevíte, zdali je vhodné použít webové služby. Potřebujete-li překročit hranice jedné platformy (například při komunikaci mezi aplikací v .NET a Javě) nebo pokud se naopak máte na tyto hranice spoléhat (například při komunikaci mezi dvěma společnostmi), má použití webových služeb velký význam. Webové služby jsou rovněž dobrou volbou, potřebujete-li použít předem vybudované funkce ASP.NET, jako je například cachování nebo různé funkce IIS (zajištění bezpečnosti prostřednictvím SSL či autentizace Windows atd.). Webové služby mají smysl i tehdy, chcete-li nechat svoji vlastní aplikaci otevřenou pro případnou budoucí integraci fukcí, které vymyslel a vytvořil někdo jiný.

Pokud chcete sdílet funkcionalitu mezi dvěma aplikacemi .NET, webové služby mohou být neúměrně velké a mohou zapříčinit zbytečné přetěžování zdrojů. Chcete-li například docílit toho, aby webové aplikace měly přístup ke specifické obchodní logice, je mnohem lepší vytvořit nějakou assembly (ve formě zkompilovaného souboru DLL) a použít ji v obou aplikacích. Tímto se vyhnete přetěžování neprocesové nebo síťové komunikace, která může velmi významná.

A konečně – pokud chcete distribuovat nějakou vaši funkcionalitu tak, aby se k ní dalo vzdáleně přístupovat, a pokud klient i server používají .NET Framework, možná byste raději měli zvážit použití technologie vzdáleného volání .NET (.NET remoting). Vzdálené volání vám sice neposkytuje stejnou úroveň podpory otevřených standardů jako třeba SOAP, dává vám ovšem svobodu použít různé typy komunikace, proprietární datové typy .NET, stavové objekty a rychlejší komunikaci založenou na TCP/IP. Stručně řečeno – vzdálené volání vám nabízí více funkcí a možnost zvýšit výkon řešení založených na .NET.

Vydělávání peněz s webovými službami Nová technologie je ztracena, neposkytuje-li nové příležitosti lidem, kteří se zabývají vyděláváním peněz.

Webové služby přinášejí z pohledu obchodníka tyto nové možnosti:

•

Nové platební struktury. Uživatel webové služby si může předplatit používání této služby. Příkladem může být dodávání zpráv z Associated Press. Další možností jsou platby za prohlížení (pou-

1210

Kapitola 32 – Tvorba webových služeb žívá se také pojem mikroplatby). Příslušný poskytovatel takové služby může provádět účtování při každém požadavku na využití služby.

•

Interakci a spolupráci v reálném čase. V dnešní době jsou data obvykle zkopírována a používána lokálně. Webové služby ovšem umožňují požádat v reálném čase o nějaká vzdálená data. Příkladem může být posílání počítačových her z internetového obchodu. Internetový obchod může být dále propojen se skladem a poskytovat aktuální počet položek na skladě. To umožňuje takovému internetovému obchodu poskytovat lepší služby. Určitě vás nevyvede z míry nic více než situace, kdy si něco objednáte přes Internet, zaplatíte, a na druhý den se dozvíte, že zboží, o které máte zájem, není momentálně skladem (nebo je rovnou vyprodáno).

•

Agregované služby. Vaše webová služba se může přičlenit k jiným webovým službám či k různým odvozeným komponentám, které jsou vystaveny pomocí proprietárních protokolů atd. Typickým příkladem agregované služby je porovnávací služba, která vám poskytuje informace o nejlepších cenách nějakého zboží. Dalším příkladem může být služba, která obsahuje několik souvisejících služeb. Představte si například, že se stěhujete do nového domu. Někdo by vám mohl poskytnout službu, která aktualizuje vaší poštovní adresu, vypátrá stěhovací společnost, která přestěhuje váš majetek, zobrazí mapu vašeho nového okolí atd.

Webové služby v žádném případě nejsou jedinou technologií, která dokáže poskytovat tato řešení. Dnes existuje mnoho různých řešení, které jsou založeny na použití existujících technologiích. Webové služby ovšem používají všeobecně respektované standardy, čímž mají potřebnou sílu k tomu, aby se všechny tyto typy služeb mohly stát široce dostupnými.

Standardy používané webovými službami Klíčem k úspěchu webových služeb je to, že jsou založeny na otevřených standardech, a že za těmito standardy stojí velké společnosti, jako je Microsoft, IBM a Sun. Otevřené standardy však automaticky nevedou ke spolupráci. Společnosti nejprve musí všechny tyto standardy implementovat, a to kompatibilním způsobem.

Při budování webových služeb se používá několik specifikací. Na obrázku 32-1 vidíte standardy, které v současnosti používají webové služby.

Obrázek 32-1. Standardy, které dnes používají webové služby.

ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně

1211

O protokolech SOAP, WSDL a UDDI, které podporují webové služby, se dozvíte mnohem více v další kapitole. Než však začnete budovat a používat webové služby, je důležité alespoň rámcově pochopit úlohu, kterou tyto standardy sehrávají. Tabulka 32-2 uvádí stručný přehled těchto standardů, přičemž v několika dalších sekcích této kapitoly si je popíšeme o něco podrobněji. Podstatně podrobněji se jimi ovšem budeme zabývat až v další kapitole.

Tabulka 32-2. Standardy webových služeb.

Standard

Popis

WSDL

Používá se na vytvoření definice rozhraní webové služby. WSDL dokument oznámí klientovi, které metody jsou ve webové službě přítomny, které parametry a návratové hodnoty jednotlivé metody používají, a jakým způsobem s nimi má komunikovat.

SOAP

Formát zprávy, který je použit pro kódování informací (jako jsou například hodnoty dat) před jejich zasláním webové službě.

HTTP

Prostřednictvím tohoto protokolu probíhá veškerá komunikace webových služeb. SOAP zprávy jsou například zasílány přes HTTP kanály.

DISCO

Používá se k vytvoření tzv. discovery dokumentů, které poskytují odkazy na více koncových bodů webové služby. Tento standard je specifický pro Microsoft a posléze bude nahrazen podobným standardem pojmenovaným jako WS-Inspection.

UDDI

Standard pro vytváření obchodních rejstříků, které registrují společnosti a webové služby, které nabízejí, a také odpovídající URL adresy jejich WSDL kontaktů.

Hledání webových služeb V jednoduchých aplikacích možná budete již předem znát URL webové služby, kterou chcete použít. V tom případě ji můžete zakódovat, nebo ji umístit do konfiguračního souboru. Není již potřeba provést žádné další kroky.

Za jiných okolností možná budete chtít v běhovém režimu hledat webovou službu, kterou potřebujete. Můžete například použít standardizovanou službu, která je poskytována různými společnostmi poskytujícími hosting a není vždy k dispozici na stejném URL. Nebo možná pouze budete potřebovat snadný způsob, jak najít všechny webové služby poskytované obchodním partnerem. V obou případech musíte použít discovery (zpřístupnění), pomocí něhož programově lokalizujete webové služby, které potřebujete.

Zpřístupnění webové služby vám usnadní dvě specifikace:

•

DISCO (což je zkratka ze slova discovery). Standard DISCO vytváří jediný soubor, který seskupuje seznam příbuzných webových služeb. Společnost může na svém serveru zveřejnit soubor DISCO, který obsahuje odkazy na všechny poskytované webové služby. Klienti, kteří chtějí najít všechny dostupné webové služby, musí o tento soubor pouze požádat. Tento postup je užitečný, když klient už zná společnost, která webové služby nabízí a chce zjistit, které služby jsou zpřístupněny, a také najít odkazy k podrobnějším informacím o těchto službách. Vyhledávání webových služeb přes Internet není sice moc efektivní, nicméně se to může hodit u lokálních sítí, kde se klient připojí na server a hned vidí, které služby jsou k dispozici a kde.

•

UDDI (Universal Description, Discovery, and Integration). UDDI je centralizovaný adresář, kam různé společnosti vkládají webové služby, které nabízejí klientům. Je to místo, kde může potenci-