Omówienie ASP.NET 4 i Visual Studio 2010 for Web Development

2023-07-13

Ten dokument zawiera omówienie wielu nowych funkcji ASP.NET, które są zawarte w programie the.NET Framework 4 i Visual Studio 2010.

Pobierz ten oficjalny dokument

Zawartość

Podstawowe usługi
Web.config
Rozszerzone buforowanie danych wyjściowych
Automatyczne uruchamianie aplikacji internetowych
Trwałe przekierowywanie strony
Zmniejszanie stanu sesji
Rozszerzanie zakresu dozwolonych adresów URL
Rozszerzalna weryfikacja żądania
Rozszerzalność buforowania obiektów i buforowania obiektów
Rozszerzalne kodowanie kodu HTML, adresu URL i nagłówka HTTP
Monitorowanie wydajności poszczególnych aplikacji w jednym procesie roboczym
Wielowersyjność

Ajax
zestaw jQuery dołączony do Web Forms i MVC
Obsługa usługi Content Delivery Network
Skrypty jawne ScriptManager

Web Forms
Ustawianie tagów meta przy użyciu właściwości Page.MetaKeywords i Page.MetaDescription
Włączanie stanu widoku dla poszczególnych kontrolek
Zmiany możliwości przeglądarki
Routing w ASP.NET 4
Ustawianie identyfikatorów klientów
Utrwalanie zaznaczenia wiersza w kontrolkach danych
wykresu _Toc253429263 ASP.NET
Filtrowanie danych za pomocą kontrolki QueryExtender
Wyrażenia kodu zakodowane w języku HTML
Zmiany szablonu projektu
Ulepszenia css
Ukrywanie elementów div wokół ukrytych pól
Renderowanie tabeli zewnętrznej dla kontrolek szablonowych
Ulepszenia kontrolki ListView
Ulepszenia kontrolek CheckBoxList i RadioButtonList
Ulepszenia kontrolki menu
Kreator i kontrolki CreateUserWizard 56

MVC
Obsługa obszarów
Obsługa walidacji atrybutów adnotacji danych
Pomocnicy z szablonami

Dane dynamiczne
Włączanie danych dynamicznych dla istniejących projektów
Deklaratywna składnia kontrolki DynamicDataManager
Szablony jednostek
Nowe szablony pól dla adresów URL i adresów e-mail
Tworzenie linków za pomocą kontrolki DynamicHyperLink
Obsługa dziedziczenia w modelu danych
Obsługa relacji wiele-do-wielu (tylko platforma Entity Framework)
Nowe atrybuty do sterowania wyświetlaniem i obsługą wyliczenia
Rozszerzona obsługa filtrów

Ulepszenia tworzenia aplikacji internetowych w programie Visual Studio 2010
Ulepszona zgodność z arkuszami CSS
Fragmenty kodu HTML i JavaScript
Ulepszenia funkcji IntelliSense języka JavaScript

Wdrażanie aplikacji internetowej za pomocą programu Visual Studio 2010
Web Packaging
_Toc253429294
Wdrażanie bazy danych
Publikowanie jednym kliknięciem dla aplikacji internetowych
Zasobów

Zastrzeżenie

Podstawowe usługi

ASP.NET 4 wprowadza szereg funkcji, które usprawniają podstawowe usługi ASP.NET, takie jak buforowanie danych wyjściowych i magazynowanie stanu sesji.

Refaktoryzacja plików Web.config

Plik Web.config zawierający konfigurację aplikacji internetowej znacznie wzrósł w ciągu ostatnich kilku wydań .NET Framework, ponieważ dodano nowe funkcje, takie jak Ajax, routing i integracja z usługami IIS 7. Utrudniło to konfigurowanie lub uruchamianie nowych aplikacji internetowych bez narzędzia takiego jak Visual Studio. W programie .NET Framework 4 główne elementy konfiguracji zostały przeniesione do machine.config pliku, a aplikacje dziedziczą te ustawienia. Web.config Dzięki temu plik w aplikacjach ASP.NET 4 może być pusty lub zawierać tylko następujące wiersze, które określają dla programu Visual Studio wersję platformy przeznaczonej dla aplikacji:

<?xml version="1.0"?>
  <configuration>
   <system.web>
    <compilation targetFramework="4.0" /> 
   </system.web>
  </configuration>

Rozszerzone buforowanie danych wyjściowych

Od czasu wydania ASP.NET 1.0 buforowanie danych wyjściowych umożliwiło deweloperom przechowywanie wygenerowanych danych wyjściowych stron, kontrolek i odpowiedzi HTTP w pamięci. W kolejnych żądaniach sieci Web ASP.NET mogą szybciej obsługiwać zawartość przez pobranie wygenerowanych danych wyjściowych z pamięci zamiast ponownego generowania danych wyjściowych od podstaw. Jednak to podejście ma ograniczenie — generowana zawartość zawsze musi być przechowywana w pamięci, a na serwerach, na których występuje duży ruch, pamięć zużywana przez buforowanie danych wyjściowych może konkurować z zapotrzebowaniem na pamięć z innych części aplikacji internetowej.

ASP.NET 4 dodaje punkt rozszerzalności do buforowania danych wyjściowych, który umożliwia skonfigurowanie co najmniej jednego niestandardowego dostawcy wyjściowej pamięci podręcznej. Dostawcy wyjściowej pamięci podręcznej mogą używać dowolnego mechanizmu magazynu do utrwalania zawartości HTML. Dzięki temu można tworzyć niestandardowych dostawców wyjściowej pamięci podręcznej dla różnych mechanizmów trwałości, które mogą obejmować dyski lokalne lub zdalne, magazyn w chmurze i rozproszone aparaty pamięci podręcznej.

Niestandardowy dostawca wyjściowej pamięci podręcznej jest tworzony jako klasa pochodząca z nowego typu System.Web.Caching.OutputCacheProvider . Następnie można skonfigurować dostawcę w Web.config pliku przy użyciu podsekcji nowych dostawców elementu outputCache , jak pokazano w poniższym przykładzie:

<caching>
  <outputCache defaultProvider="AspNetInternalProvider">
    <providers>
      <add name="DiskCache"
          type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>
    </providers>
  </outputCache>

</caching>

Domyślnie w ASP.NET 4 wszystkie odpowiedzi HTTP, renderowane strony i kontrolki używają pamięci podręcznej danych wyjściowych w pamięci, jak pokazano w poprzednim przykładzie, gdzie atrybut defaultProvider jest ustawiony na AspNetInternalProvider. Możesz zmienić domyślnego dostawcę wyjściowej pamięci podręcznej używanego dla aplikacji internetowej, określając inną nazwę dostawcy dla domyślnego dostawcy.

Ponadto można wybrać różnych dostawców pamięci podręcznej danych wyjściowych na kontrolkę i na żądanie. Najprostszym sposobem wybrania innego dostawcy wyjściowej pamięci podręcznej dla różnych kontrolek użytkownika sieci Web jest wykonanie tej czynności deklaratywnej przy użyciu nowego atrybutu providerName w dyrektywie sterującej, jak pokazano w poniższym przykładzie:

<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>

Określenie innego dostawcy wyjściowej pamięci podręcznej dla żądania HTTP wymaga nieco więcej pracy. Zamiast deklaratywnie określać dostawcę, należy zastąpić nową metodę GetOuputCacheProviderName w pliku w Global.asax celu programowego określenia dostawcy, który ma być używany dla określonego żądania. W przykładzie poniżej pokazano, jak to zrobić.

public override string GetOutputCacheProviderName(HttpContext context)
{
    if (context.Request.Path.EndsWith("Advanced.aspx"))
       return "DiskCache";
    else
        return base.GetOutputCacheProviderName(context);
}

Dzięki dodaniu rozszerzalności dostawcy wyjściowej pamięci podręcznej do ASP.NET 4 można teraz realizować bardziej agresywne i bardziej inteligentne strategie buforowania danych wyjściowych dla witryn sieci Web. Na przykład teraz można buforować strony "10 pierwszych" witryny w pamięci, podczas gdy buforowanie stron, które uzyskują mniejszy ruch na dysku. Alternatywnie można buforować wszystkie różne kombinacje dla renderowanej strony, ale użyć rozproszonej pamięci podręcznej, aby zużycie pamięci zostało odciążone z serwerów frontonu sieci Web.

Automatyczne uruchamianie aplikacji internetowych

Niektóre aplikacje internetowe muszą ładować duże ilości danych lub wykonywać kosztowne przetwarzanie inicjowania przed obsługą pierwszego żądania. We wcześniejszych wersjach ASP.NET w takich sytuacjach trzeba było opracować niestandardowe podejścia do "wznawiania" aplikacji ASP.NET, a następnie uruchamiać kod inicjowania podczas metody Application_Load w Global.asax pliku.

Nowa funkcja skalowania o nazwie auto-start , która bezpośrednio dotyczy tego scenariusza, jest dostępna, gdy ASP.NET 4 działa w usługach IIS 7.5 w systemie Windows Server 2008 R2. Funkcja automatycznego uruchamiania zapewnia kontrolowane podejście do uruchamiania puli aplikacji, inicjowania aplikacji ASP.NET, a następnie akceptowania żądań HTTP.

Uwaga

Moduł Warm-Up aplikacji iis dla usług IIS 7.5

Zespół usług IIS wydał pierwszą wersję beta modułu Application Warm-Up Module dla usług IIS 7.5. To sprawia, że rozgrzewanie aplikacji jest jeszcze łatwiejsze niż wcześniej opisane. Zamiast pisać kod niestandardowy, należy określić adresy URL zasobów do wykonania przed zaakceptowaniem żądań z sieci przez aplikację internetową. Ta rozgrzewka występuje podczas uruchamiania usługi IIS (jeśli skonfigurowano pulę aplikacji USŁUG IIS jako AlwaysRunning) i gdy proces roboczy usług IIS przetwarza ponownie. Podczas recyklingu stary proces roboczy usług IIS kontynuuje wykonywanie żądań, dopóki nowo zduplikowany proces roboczy nie zostanie w pełni rozgrzany, dzięki czemu aplikacje nie będą mieć przerw w działaniu ani innych problemów z powodu nieprzyjanych pamięci podręcznych. Należy pamiętać, że ten moduł współpracuje z dowolną wersją ASP.NET, począwszy od wersji 2.0.

Aby uzyskać więcej informacji, zobacz Temat Rozgrzewka aplikacji w witrynie sieci Web IIS.net. Aby zapoznać się z przewodnikiem przedstawiającym sposób korzystania z funkcji rozgrzewki, zobacz Wprowadzenie z modułem Warm-Up aplikacji usług IIS 7.5 w witrynie sieci Web IIS.net.

Aby użyć funkcji automatycznego uruchamiania, administrator usług IIS ustawia pulę aplikacji w usługach IIS 7.5 do automatycznego uruchamiania przy użyciu następującej applicationHost.config konfiguracji w pliku:

<applicationpools>
  <add name="MyApplicationPool" startMode="AlwaysRunning" />
</applicationpools>

Ponieważ pojedyncza pula aplikacji może zawierać wiele aplikacji, należy określić poszczególne aplikacje do automatycznego uruchamiania przy użyciu następującej applicationHost.config konfiguracji w pliku:

<sites>
  <site name="MySite" id="1">
    <application path="/" 
      serviceAutoStartEnabled="true"
      serviceAutoStartProvider="PrewarmMyCache" >
      <!-- Additional content -->
    </application>
  </site>

</sites>

<!-- Additional content -->

<serviceautostartproviders>
  <add name="PrewarmMyCache"
    type="MyNamespace.CustomInitialization, MyLibrary" />
</serviceautostartproviders>

Gdy serwer usług IIS 7.5 jest uruchamiany na zimno lub gdy pojedyncza pula aplikacji jest odzyskiwanych, usługi IIS 7.5 używają informacji w pliku w applicationHost.config celu określenia, które aplikacje internetowe muszą być uruchamiane automatycznie. Dla każdej aplikacji oznaczonej do automatycznego uruchamiania usługi IIS7.5 wysyła żądanie do ASP.NET 4 w celu uruchomienia aplikacji w stanie, w którym aplikacja tymczasowo nie akceptuje żądań HTTP. Gdy znajduje się on w tym stanie, ASP.NET utworzy wystąpienie typu zdefiniowanego przez atrybut serviceAutoStartProvider (jak pokazano w poprzednim przykładzie) i wywołuje go do publicznego punktu wejścia.

Typ zarządzanego automatycznego uruchamiania można utworzyć z niezbędnym punktem wejścia, implementując interfejs IProcessHostPreloadClient , jak pokazano w poniższym przykładzie:

public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        // Perform initialization. 
    }
}

Po uruchomieniu kodu inicjowania w metodzie Preload i zwracaniu metody aplikacja ASP.NET jest gotowa do przetwarzania żądań.

Po dodaniu automatycznego uruchamiania do usług IIS .5 i ASP.NET 4 masz teraz dobrze zdefiniowane podejście do wykonywania kosztownej inicjowania aplikacji przed przetworzeniem pierwszego żądania HTTP. Na przykład możesz użyć nowej funkcji automatycznego uruchamiania, aby zainicjować aplikację, a następnie zasygnalizować moduł równoważenia obciążenia, który został zainicjowany i gotowy do akceptowania ruchu HTTP.

Trwałe przekierowywanie strony

Często zdarza się w aplikacjach internetowych przenoszenie stron i innych treści w czasie, co może prowadzić do gromadzenia nieaktualnych linków w wyszukiwarkach. W ASP.NET deweloperzy tradycyjnie obsługiwali żądania do starych adresów URL przy użyciu metody Response.Redirect w celu przekazania żądania do nowego adresu URL. Jednak metoda przekierowania wystawia odpowiedź HTTP 302 Found (tymczasowe przekierowanie), co powoduje dodatkową podróż okrężną HTTP, gdy użytkownicy próbują uzyskać dostęp do starych adresów URL.

ASP.NET 4 dodaje nową metodę pomocnika RedirectPermanent , która ułatwia wystawianie odpowiedzi HTTP 301 przeniesionych trwale, jak w poniższym przykładzie:

RedirectPermanent("/newpath/foroldcontent.aspx");

Aparaty wyszukiwania i inni agenci użytkowników, którzy rozpoznają trwałe przekierowania, będą przechowywać nowy adres URL skojarzony z zawartością, co eliminuje niepotrzebne rundy wykonane przez przeglądarkę na potrzeby tymczasowych przekierowań.

Zmniejszanie stanu sesji

ASP.NET udostępnia dwie domyślne opcje przechowywania stanu sesji w farmie sieci Web: dostawcy stanu sesji, który wywołuje serwer stanu sesji poza procesem oraz dostawcę stanu sesji, który przechowuje dane w bazie danych microsoft SQL Server. Ponieważ obie opcje obejmują przechowywanie informacji o stanie poza procesem roboczym aplikacji internetowej, stan sesji musi być serializowany przed wysłaniem ich do magazynu zdalnego. W zależności od ilości informacji, które deweloper zapisuje w stanie sesji, rozmiar serializowanych danych może rosnąć dość duże.

ASP.NET 4 wprowadza nową opcję kompresji dla obu rodzajów dostawców stanu sesji poza procesem. Gdy opcja konfiguracji compressionEnabled pokazana w poniższym przykładzie ma wartość true, ASP.NET będzie kompresować (i dekompresować) stan sesji serializowanej przy użyciu klasy .NET Framework System.IO.Compression.GZipStream.

<sessionState
  mode="SqlServer"
  sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
  allowCustomSqlDatabase="true"
  compressionEnabled="true"
/>

Dzięki prostemu dodaniu nowego atrybutu do Web.config pliku aplikacje z wolnymi cyklami procesora CPU na serwerach sieci Web mogą zdawać sobie sprawę ze znacznego zmniejszenia rozmiaru serializowanych danych stanu sesji.

Rozszerzanie zakresu dozwolonych adresów URL

ASP.NET 4 wprowadza nowe opcje rozszerzania rozmiaru adresów URL aplikacji. Poprzednie wersje ASP.NET ograniczonych długości ścieżki adresu URL do 260 znaków na podstawie limitu ścieżki plików NTFS. W ASP.NET 4 masz możliwość zwiększenia (lub zmniejszenia) tego limitu zgodnie z potrzebami dla aplikacji przy użyciu dwóch nowych atrybutów konfiguracji httpRuntime . W poniższym przykładzie przedstawiono te nowe atrybuty.

<httpRuntime maxUrlLength="260" maxQueryStringLength="2048" />

Aby zezwolić na dłuższe lub krótsze ścieżki (część adresu URL, która nie zawiera protokołu, nazwy serwera i ciągu zapytania), zmodyfikuj atrybut maxUrlLength . Aby zezwolić na dłuższe lub krótsze ciągi zapytania, zmodyfikuj wartość atrybutu maxQueryStringLength .

ASP.NET 4 umożliwia również skonfigurowanie znaków używanych przez sprawdzanie znaków adresu URL. Gdy ASP.NET znajdzie nieprawidłowy znak w części ścieżki adresu URL, odrzuca żądanie i wystawia błąd HTTP 400. W poprzednich wersjach ASP.NET sprawdzanie znaków adresu URL było ograniczone do stałego zestawu znaków. W ASP.NET 4 można dostosować zestaw prawidłowych znaków przy użyciu nowego atrybutu requestPathInvalidCharacters elementu konfiguracji httpRuntime , jak pokazano w poniższym przykładzie:

<httpRuntime requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,:,\,?"  />

Domyślnie atrybut requestPathInvalidCharacters definiuje osiem znaków jako nieprawidłowy. (W ciągu przypisanym do requestPathInvalidCharacters domyślnie mniejsze niż (), większe niż (<>) i znaki ampersand (&) są kodowane, ponieważ Web.config plik jest plikiem XML. W razie potrzeby można dostosować zestaw nieprawidłowych znaków.

Uwaga

Uwaga ASP.NET 4 zawsze odrzuca ścieżki adresu URL, które zawierają znaki w zakresie ASCII 0x00 do 0x1F, ponieważ są to nieprawidłowe znaki adresu URL zdefiniowane w dokumencie RFC 2396 pliku IETF (http://www.ietf.org/rfc/rfc2396.txt). W wersjach systemu Windows Server z uruchomionymi usługami IIS 6 lub nowszym sterownik urządzenia protokołu http.sys automatycznie odrzuca adresy URL z tymi znakami.

Rozszerzalna weryfikacja żądania

ASP.NET żądania weryfikacji wyszukuje przychodzące dane żądania HTTP dla ciągów, które są często używane w atakach skryptów międzylokacyjnych (XSS). Jeśli zostaną znalezione potencjalne ciągi XSS, żądanie oznacza flagę weryfikacji podejrzanego ciągu i zwraca błąd. Wbudowana weryfikacja żądania zwraca błąd tylko wtedy, gdy znajdzie najbardziej typowe ciągi używane w atakach XSS. Poprzednie próby zwiększenia agresywności weryfikacji XSS spowodowały zbyt wiele wyników fałszywie dodatnich. Jednak klienci mogą chcieć zażądać weryfikacji, która jest bardziej agresywna, lub odwrotnie może chcieć celowo rozluźnić sprawdzanie XSS pod kątem określonych stron lub określonych typów żądań.

W ASP.NET 4 funkcja weryfikacji żądań została rozszerzalna, aby można było użyć niestandardowej logiki weryfikacji żądań. Aby rozszerzyć walidację żądania, należy utworzyć klasę pochodzącą z nowego typu System.Web.Util.RequestValidator i skonfigurować aplikację (w sekcji httpRuntime pliku), aby używać typu niestandardowego Web.config . W poniższym przykładzie pokazano, jak skonfigurować niestandardową klasę weryfikacji żądań:

<httpRuntime requestValidationType="Samples.MyValidator, Samples" />

Nowy atrybut requestValidationType wymaga standardowego ciągu identyfikatora typu .NET Framework, który określa klasę, która zapewnia niestandardową walidację żądania. Dla każdego żądania ASP.NET wywołuje typ niestandardowy do przetwarzania każdego elementu przychodzących danych żądania HTTP. Przychodzący adres URL, wszystkie nagłówki HTTP (zarówno pliki cookie, jak i nagłówki niestandardowe), a treść jednostki są dostępne do inspekcji przez niestandardową klasę weryfikacji żądań, jak pokazano w poniższym przykładzie:

public class CustomRequestValidation : RequestValidator
{
    protected override bool IsValidRequestString(
      HttpContext context, string value, 
      RequestValidationSource requestValidationSource, 
      string collectionKey, 
      out int validationFailureIndex) 
    {...}
 }

W przypadku, gdy nie chcesz sprawdzać fragmentu przychodzących danych HTTP, klasa weryfikacji żądań może wrócić, aby umożliwić ASP.NET domyślnej weryfikacji żądań, uruchamiając po prostu wywołanie bazy. Isvalidrequeststring.

Rozszerzalność buforowania obiektów i buforowania obiektów

Od pierwszej wersji ASP.NET zawiera zaawansowaną pamięć podręczną obiektów w pamięci (System.Web.Caching.Cache). Implementacja pamięci podręcznej była tak popularna, że została użyta w aplikacjach innych niż web. Jest to jednak niezręczne dla aplikacji Windows Forms lub WPF, aby dołączyć odwołanie tylko do System.Web.dll możliwości korzystania z pamięci podręcznej obiektów ASP.NET.

Aby udostępnić buforowanie dla wszystkich aplikacji, .NET Framework 4 wprowadza nowy zestaw, nową przestrzeń nazw, niektóre typy podstawowe i konkretną implementację buforowania. Nowy System.Runtime.Caching.dll zestaw zawiera nowy interfejs API buforowania w przestrzeni nazw System.Runtime.Caching . Przestrzeń nazw zawiera dwa podstawowe zestawy klas:

Typy abstrakcyjne, które stanowią podstawę do tworzenia dowolnego typu implementacji niestandardowej pamięci podręcznej.
Konkretna implementacja pamięci podręcznej obiektów w pamięci (klasa System.Runtime.Caching.MemoryCache ).

Nowa klasa MemoryCache jest ściśle wzorowana na pamięci podręcznej ASP.NET i współdzieli większość wewnętrznej logiki aparatu pamięci podręcznej z ASP.NET. Mimo że publiczne interfejsy API buforowania w systemie System.Runtime.Caching zostały zaktualizowane w celu obsługi tworzenia niestandardowych pamięci podręcznych, jeśli użyto obiektu ASP.NET Cache , poznasz znane pojęcia w nowych interfejsach API.

Szczegółowa dyskusja na temat nowej klasy MemoryCache i pomocniczych podstawowych interfejsów API wymaga całego dokumentu. Jednak w poniższym przykładzie przedstawiono sposób działania nowego interfejsu API pamięci podręcznej. Przykład został napisany dla aplikacji Windows Forms bez zależności od System.Web.dllelementu .

private void btnGet_Click(object sender, EventArgs e) 
{ 
    //Obtain a reference to the default MemoryCache instance. 
    //Note that you can create multiple MemoryCache(s) inside 
    //of a single application. 
    ObjectCache cache = MemoryCache.Default; 

    //In this example the cache is storing the contents of a file string 
    fileContents = cache["filecontents"] as string;

    //If the file contents are not currently in the cache, then 
    //the contents are read from disk and placed in the cache. 
    if (fileContents == null) 
    {
        //A CacheItemPolicy object holds all the pieces of cache 
        //dependency and cache expiration metadata related to a single 
        //cache entry. 
        CacheItemPolicy policy = new CacheItemPolicy(); 

        //Build up the information necessary to create a file dependency. 
        //In this case we just need the file path of the file on disk. 
        List filePaths = new List(); 
        filePaths.Add("c:\\data.txt"); 

        //In the new cache API, dependencies are called "change monitors". 
        //For this example we want the cache entry to be automatically expired 
        //if the contents on disk change. A HostFileChangeMonitor provides 
        //this functionality. 
        policy.ChangeMonitors.Add(new HostFileChangeMonitor(filePaths)); 

        //Fetch the file's contents 
        fileContents = File.ReadAllText("c:\\data.txt"); 

        //And then store the file's contents in the cache 
        cache.Set("filecontents", fileContents, policy); 

    } 
    MessageBox.Show(fileContents); 
}

Rozszerzalne kodowanie kodu HTML, adresu URL i nagłówka HTTP

W ASP.NET 4 można utworzyć niestandardowe procedury kodowania dla następujących typowych zadań kodowania tekstu:

Kodowanie HTML.
Kodowanie adresów URL.
Kodowanie atrybutów HTML.
Kodowanie wychodzących nagłówków HTTP.

Koder niestandardowy można utworzyć, korzystając z nowego typu System.Web.Util.HttpEncoder, a następnie konfigurując ASP.NET do używania typu niestandardowego w sekcji Web.confighttpRuntime pliku, jak pokazano w poniższym przykładzie:

<httpRuntime encoderType="Samples.MyCustomEncoder, Samples" />

Po skonfigurowaniu kodera niestandardowego ASP.NET automatycznie wywołuje implementację kodowania niestandardowego za każdym razem, gdy są wywoływane publiczne metody kodowania System.Web.HttpUtility lub System.Web.HttpServerUtility . Dzięki temu jedna część zespołu deweloperów internetowych tworzy koder niestandardowy, który implementuje agresywne kodowanie znaków, podczas gdy reszta zespołu deweloperów sieci Web nadal korzysta z publicznych interfejsów API kodowania ASP.NET. Dzięki centralnej konfiguracji kodera niestandardowego w elemecie httpRuntime gwarantuje się, że wszystkie wywołania kodowania tekstu z publicznych interfejsów API kodowania ASP.NET są kierowane przez koder niestandardowy.

Monitorowanie wydajności poszczególnych aplikacji w jednym procesie roboczym

Aby zwiększyć liczbę witryn sieci Web, które mogą być hostowane na jednym serwerze, wielu hostujących uruchamia wiele ASP.NET aplikacji w jednym procesie roboczym. Jeśli jednak wiele aplikacji korzysta z jednego współużytkowanego procesu roboczego, administratorzy serwera trudno jest zidentyfikować pojedynczą aplikację, która ma problemy.

ASP.NET 4 wykorzystuje nowe funkcje monitorowania zasobów wprowadzone przez clR. Aby włączyć tę funkcję, możesz dodać następujący fragment kodu konfiguracji XML do aspnet.config pliku konfiguracji.

<?xml version="1.0" encoding="UTF-8" ?> 
<configuration> 
  <runtime> 
    <appDomainResourceMonitoring enabled="true"/> 
  </runtime> 

</configuration>

Uwaga

Uwaga Plik aspnet.config znajduje się w katalogu, w którym zainstalowano .NET Framework. Nie jest Web.config to plik.

Po włączeniu funkcji appDomainResourceMonitoring dwie nowe liczniki wydajności są dostępne w kategorii wydajności "aplikacje ASP.NET": % czasu procesora zarządzanego i używanej pamięci zarządzanej. Oba te liczniki wydajności używają nowej funkcji zarządzania zasobami domeny aplikacji CLR do śledzenia szacowanego czasu procesora CPU i wykorzystania pamięci zarządzanej poszczególnych aplikacji ASP.NET. W związku z tym w przypadku ASP.NET 4 administratorzy mają teraz bardziej szczegółowy wgląd w użycie zasobów poszczególnych aplikacji działających w jednym procesie roboczym.

Wielowersyjność kodu

Możesz utworzyć aplikację przeznaczoną dla określonej wersji .NET Framework. W ASP.NET 4 nowy atrybut w elemecie Web.configkompilacji pliku umożliwia określanie wartości docelowej .NET Framework 4 i nowszych. Jeśli jawnie celujesz w .NET Framework 4, a jeśli w pliku zostaną uwzględnione opcjonalne elementyWeb.config, takie jak wpisy dla pliku system.codedom, te elementy muszą być poprawne dla .NET Framework 4. (Jeśli nie zostanie jawnie skierowane .NET Framework 4, struktura docelowa zostanie wywnioskowana z braku wpisu w Web.config pliku).

W poniższym przykładzie pokazano użycie atrybutu targetFramework w elemecie kompilacjiWeb.config pliku.

<compilation targetFramework="4.0"/>

Zwróć uwagę na następujące informacje dotyczące określania wartości docelowej dla określonej wersji .NET Framework:

W puli aplikacji .NET Framework 4 system kompilacji ASP.NET zakłada, że .NET Framework 4 jako element docelowy, jeśli Web.config plik nie zawiera atrybutu targetFramework lub jeśli Web.config brakuje pliku. (Może być konieczne wprowadzenie zmian w kodowaniu w aplikacji, aby była uruchamiana w .NET Framework 4).
Jeśli dołączysz atrybut targetFramework, a element system.codeDom jest zdefiniowany w Web.config pliku, ten plik musi zawierać poprawne wpisy dla .NET Framework 4.
Jeśli używasz polecenia aspnet_compiler , aby wstępnie skompilować aplikację (na przykład w środowisku kompilacji), musisz użyć poprawnej wersji polecenia aspnet_compiler dla platformy docelowej. Kompilator dostarczany z .NET Framework 2.0 (%WINDIR%\Microsoft.NET\Framework\v2.0.50727) umożliwia skompilowanie dla .NET Framework 3.5 i starszych wersji. Kompilator dostarczany z .NET Framework 4 umożliwia kompilowanie aplikacji utworzonych przy użyciu tej platformy lub nowszych wersji.
W czasie wykonywania kompilator używa najnowszych zestawów struktur zainstalowanych na komputerze (i w związku z tym w pamięci GAC). Jeśli aktualizacja zostanie później wprowadzonych do platformy (na przykład jest zainstalowana hipotetyczna wersja 4.1), będzie można używać funkcji w nowszej wersji platformy, mimo że atrybut targetFramework jest przeznaczony dla niższej wersji (np. 4.0). (Jednak w czasie projektowania w programie Visual Studio 2010 lub w przypadku korzystania z polecenia aspnet_compiler użycie nowszych funkcji platformy spowoduje błędy kompilatora).

AJAX

Zestaw jQuery dołączony do Web Forms i MVC

Szablony programu Visual Studio dla Web Forms i MVC obejmują bibliotekę jQuery typu open source. Podczas tworzenia nowej witryny internetowej lub projektu tworzony jest folder Scripts zawierający następujące 3 pliki:

jQuery-1.4.1.js — czytelna dla człowieka, niezminyfikowana wersja biblioteki jQuery.
jQuery-14.1.min.js — minimalna wersja biblioteki jQuery.
jQuery-1.4.1-vsdoc.js — plik dokumentacji funkcji IntelliSense dla biblioteki jQuery.

Uwzględnij niezminyfikowaną wersję zapytania jQuery podczas tworzenia aplikacji. Uwzględnij minimalną wersję zapytania jQuery dla aplikacji produkcyjnych.

Na przykład na poniższej stronie Web Forms pokazano, jak za pomocą zapytania jQuery zmienić kolor tła kontrolek ASP.NET TextBox na żółtą, gdy mają fokus.

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="ShowjQuery.aspx.cs" Inherits="ShowjQuery" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">
    <title>Show jQuery</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>

        <asp:TextBox ID="txtFirstName" runat="server" />
        <br />
        <asp:TextBox ID="txtLastName" runat="server" />
    </div>
    </form>
    <script src="Scripts/jquery-1.4.1.js" type="text/javascript"></script>

    <script type="text/javascript">
    
        $("input").focus( function() { $(this).css("background-color", "yellow"); });
    
    </script>
</body>
</html>

Obsługa usługi Content Delivery Network

Usługa Microsoft Ajax Content Delivery Network (CDN) umożliwia łatwe dodawanie skryptów ASP.NET Ajax i jQuery do aplikacji internetowych. Na przykład możesz rozpocząć korzystanie z biblioteki jQuery, dodając <script> tag do strony, który wskazuje Ajax.microsoft.com w następujący sposób:

<script src="https://ajax.aspnetcdn.com/ajax/jquery/jquery-1.4.2.js" type="text/javascript"></script>

Korzystając z usługi Microsoft Ajax CDN, można znacznie poprawić wydajność aplikacji Ajax. Zawartość usługi Microsoft Ajax CDN jest buforowana na serwerach znajdujących się na całym świecie. Ponadto usługa Microsoft Ajax CDN umożliwia przeglądarkom ponowne używanie buforowanych plików JavaScript dla witryn sieci Web znajdujących się w różnych domenach.

Usługa Microsoft Ajax Content Delivery Network obsługuje protokół SSL (HTTPS) na wypadek potrzeby udostępniania strony internetowej przy użyciu protokołu Secure Sockets Layer.

Zaimplementuj rezerwę, gdy sieć CDN jest niedostępna. Przetestuj rezerwę.

Aby dowiedzieć się więcej o usłudze Microsoft Ajax CDN, odwiedź następującą witrynę internetową:

https://www.asp.net/ajaxlibrary/CDN.ashx

ASP.NET ScriptManager obsługuje usługę Microsoft Ajax CDN. Wystarczy ustawić jedną właściwość EnableCdn, aby pobrać wszystkie pliki JavaScript platformy ASP.NET z sieci CDN:

<asp:ScriptManager ID="sm1" EnableCdn="true" runat="server" />

Po ustawieniu właściwości EnableCdn na wartość true platforma ASP.NET pobierze wszystkie pliki JavaScript platformy ASP.NET z sieci CDN, w tym wszystkie pliki JavaScript używane do walidacji i UpdatePanel. Ustawienie tej właściwości może mieć znaczący wpływ na wydajność aplikacji internetowej.

Ścieżkę cdN dla własnych plików JavaScript można ustawić przy użyciu atrybutu WebResource. Nowa właściwość CdnPath określa ścieżkę do sieci CDN używanej podczas ustawiania właściwości EnableCdn na wartość true:

[assembly: WebResource("Foo.js", "application/x-javascript", CdnPath = "http://foo.com/foo/bar/foo.js")]

Skrypty jawne ScriptManager

Jeśli w przeszłości użyto ASP.NET ScriptManger, konieczne było załadowanie całej monolitycznej biblioteki ASP.NET Ajax. Korzystając z nowej właściwości ScriptManager.AjaxFrameworkMode, można kontrolować dokładnie, które składniki biblioteki ASP.NET Ajax są ładowane i ładować tylko składniki biblioteki ASP.NET Ajax, których potrzebujesz.

Właściwość ScriptManager.AjaxFrameworkMode można ustawić na następujące wartości:

Włączone — określa, że kontrolka ScriptManager automatycznie zawiera plik skryptu MicrosoftAjax.js, który jest połączonym plikiem skryptu każdego podstawowego skryptu platformy (starsze zachowanie).
Wyłączone — określa, że wszystkie funkcje skryptu Microsoft Ajax są wyłączone i że kontrolka ScriptManager nie odwołuje się automatycznie do żadnych skryptów.
Jawne — określa, że jawnie dołączysz odwołania skryptu do pojedynczego pliku skryptu podstawowego platformy wymaganego przez twoją stronę i że dołączysz odwołania do zależności wymaganych przez każdy plik skryptu.

Jeśli na przykład ustawisz właściwość AjaxFrameworkMode na wartość Jawna, możesz określić określone skrypty składników Ajax ASP.NET, które są potrzebne:

<asp:ScriptManager ID="sm1" AjaxFrameworkMode="Explicit" runat="server">

<Scripts>
    <asp:ScriptReference Name="MicrosoftAjaxCore.js" />
    <asp:ScriptReference Name="MicrosoftAjaxComponentModel.js" />
    <asp:ScriptReference Name="MicrosoftAjaxSerialization.js" />
    <asp:ScriptReference Name="MicrosoftAjaxNetwork.js" />    
</Scripts>
</asp:ScriptManager>

Formularze sieci Web

Web Forms jest główną funkcją w ASP.NET od czasu wydania ASP.NET 1.0. W tym obszarze wprowadzono wiele ulepszeń dla ASP.NET 4, w tym:

Możliwość ustawiania tagów meta .
Większa kontrola nad stanem widoku.
Łatwiejsze sposoby pracy z funkcjami przeglądarki.
Obsługa używania routingu ASP.NET z Web Forms.
Większa kontrola nad wygenerowanymi identyfikatorami.
Możliwość utrwalania wybranych wierszy w kontrolkach danych.
Większa kontrola nad renderowaną zawartością HTML w kontrolkach FormView i ListView .
Obsługa filtrowania kontrolek źródła danych.

Ustawianie tagów meta przy użyciu właściwości Page.MetaKeywords i Page.MetaDescription

ASP.NET 4 dodaje dwie właściwości do klasy Page , MetaKeywords i MetaDescription. Te dwie właściwości reprezentują odpowiednie tagi meta na stronie, jak pokazano w poniższym przykładzie:

<head id="Head1" runat="server"> 
  <title>Untitled Page</title> 
  <meta name="keywords" content="These, are, my, keywords" /> 
  <meta name="description" content="This is the description of my page" /> 
</head>

Te dwie właściwości działają tak samo, jak właściwość Title strony. Są one zgodne z następującymi regułami:

Jeśli w elemecie head nie ma tagów meta pasujących do nazw właściwości (czyli name="keywords" dla Page.MetaKeywords i name="description" dla page.MetaDescription, co oznacza, że te właściwości nie zostały ustawione), tagi meta zostaną dodane do strony podczas renderowania.
Jeśli istnieją już tagi meta o tych nazwach, te właściwości działają jak get i ustawiają metody zawartości istniejących tagów.

Te właściwości można ustawić w czasie wykonywania, co umożliwia pobranie zawartości z bazy danych lub innego źródła, a także dynamiczne ustawianie tagów w celu opisania konkretnej strony.

Właściwości Słowa kluczowe i Opis można również ustawić w dyrektywie @ Page w górnej części znacznika strony Web Forms, jak w poniższym przykładzie:

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeFile="Default.aspx.cs" 
  Inherits="_Default" 
  Keywords="These, are, my, keywords" 
  Description="This is a description" %>

Spowoduje to zastąpienie zawartości tagu meta (jeśli istnieje) już zadeklarowanej na stronie.

Zawartość tagu meta opisu służy do ulepszania podglądów list wyszukiwania w google. (Aby uzyskać szczegółowe informacje, zobacz Ulepszanie fragmentów kodu z metaopisem na blogu Google Administrator Central). Google i Windows Live Search nie używają treści słów kluczowych dla niczego, ale inne wyszukiwarki mogą.

Te nowe właściwości są prostą funkcją, ale pozwalają zaoszczędzić ci na konieczności ręcznego dodania tych właściwości lub utworzenia własnego kodu w celu utworzenia tagów meta .

Włączanie stanu widoku dla poszczególnych kontrolek

Domyślnie stan widoku jest włączony dla strony z wynikiem, że każda kontrolka na stronie potencjalnie przechowuje stan widoku, nawet jeśli nie jest to wymagane dla aplikacji. Dane stanu wyświetlania są uwzględniane w znacznikach generowanych przez stronę i wydłuża czas potrzebny na wysłanie strony do klienta i opublikowanie jej z powrotem. Przechowywanie większego stanu widoku, niż jest to konieczne, może spowodować znaczne obniżenie wydajności. We wcześniejszych wersjach ASP.NET deweloperzy mogą wyłączyć stan wyświetlania poszczególnych kontrolek w celu zmniejszenia rozmiaru strony, ale musieli to zrobić jawnie dla poszczególnych kontrolek. W ASP.NET 4 kontrolki serwera sieci Web zawierają właściwość ViewStateMode , która umożliwia domyślne wyłączenie stanu widoku, a następnie włączenie go tylko dla kontrolek, które wymagają go na stronie.

Właściwość ViewStateMode przyjmuje wyliczenie z trzema wartościami: Włączone, Wyłączone i Dziedziczone. Włączone włącza stan widoku dla tej kontrolki i dla wszystkich kontrolek podrzędnych, które są ustawione na Dziedzicz lub które nie mają ustawionego stanu. Wyłączone wyłącza stan widoku, a dziedzicz określa, że kontrolka używa ustawienia ViewStateMode z kontrolki nadrzędnej.

W poniższym przykładzie pokazano, jak działa właściwość ViewStateMode . Znaczniki i kod kontrolek na następującej stronie zawierają wartości właściwości ViewStateMode :

<form id="form1" runat="server"> 
  <script runat="server"> 
      protected override void OnLoad(EventArgs e) { 
      if (!IsPostBack) { 
        label1.Text = label2.Text = "[DynamicValue]"; 
      } 
      base.OnLoad(e); 
    } 
  </script> 
  <asp:PlaceHolder ID="PlaceHolder1" runat="server" ViewStateMode="Disabled"> 
      Disabled: <asp:Label ID="label1" runat="server" Text="[DeclaredValue]" /><br /> 
    <asp:PlaceHolder ID="PlaceHolder2" runat="server" ViewStateMode="Enabled"> 
        Enabled: <asp:Label ID="label2" runat="server" Text="[DeclaredValue]" /> 
    </asp:PlaceHolder> 
  </asp:PlaceHolder> 
  <hr /> 
  <asp:button ID="Button1" runat="server" Text="Postback" /> 
  <%-- Further markup here --%>

Jak widać, kod wyłącza stan widoku dla kontrolki PlaceHolder1. Kontrolka etykieta1 podrzędna dziedziczy tę wartość właściwości (Dziedzicz jest wartością domyślną dla kontrolki ViewStateMode ). W związku z tym nie zapisuje stanu widoku. W kontrolce PlaceHolder2 właściwość ViewStateMode jest ustawiona na Włączone, dlatego właściwość label2 dziedziczy tę właściwość i zapisuje stan widoku. Po pierwszym załadowaniu strony właściwość Text obu kontrolek Etykieta jest ustawiana na ciąg "[DynamicValue]".

Efektem tych ustawień jest to, że gdy strona zostanie załadowana po raz pierwszy, w przeglądarce zostaną wyświetlone następujące dane wyjściowe:

Wyłączone : [DynamicValue]

Włączone:[DynamicValue]

Po zakończeniu ogłaszania zwrotnego zostaną jednak wyświetlone następujące dane wyjściowe:

Wyłączone : [DeclaredValue]

Włączone:[DynamicValue]

Kontrolka label1 (której wartość ViewStateMode jest ustawiona na wartość Disabled) nie zachowała wartości ustawionej w kodzie. Jednak kontrolka label2 (której wartość ViewStateMode jest ustawiona na Włączone) zachowała swój stan.

Można również ustawić tryb ViewStateMode w dyrektywie @ Page , jak w poniższym przykładzie:

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeBehind="Default.aspx.cs" 
  Inherits="WebApplication1._Default" 
  ViewStateMode="Disabled" %>

Klasa Page jest po prostu kolejną kontrolką; pełni rolę kontrolki nadrzędnej dla wszystkich innych kontrolek na stronie. Wartość domyślna ViewStateMode jest włączona dla wystąpień strony. Ponieważ kontrolki są domyślnie dziedziczone, kontrolki dziedziczą wartość właściwości Włączone , chyba że ustawisz tryb ViewStateMode na poziomie strony lub kontrolki.

Wartość właściwości ViewStateMode określa, czy stan widoku jest utrzymywany tylko wtedy, gdy właściwość EnableViewState jest ustawiona na true. Jeśli właściwość EnableViewState ma wartość false, stan widoku nie zostanie zachowany, nawet jeśli właściwość ViewStateMode jest ustawiona na wartość Włączone.

Dobrą funkcją jest użycie kontrolek ContentPlaceHolder na stronach wzorcowych, w których można ustawić wartość ViewStateMode na wartość Disabled dla strony wzorcowej, a następnie włączyć ją indywidualnie dla kontrolek ContentPlaceHolder , które z kolei zawierają kontrolki wymagające stanu widoku.

Zmiany możliwości przeglądarki

ASP.NET określa możliwości przeglądarki używane przez użytkownika do przeglądania witryny za pomocą funkcji o nazwie możliwości przeglądarki. Możliwości przeglądarki są reprezentowane przez obiekt HttpBrowserCapabilities (uwidoczniony przez właściwość Request.Browser ). Na przykład można użyć obiektu HttpBrowserCapabilities , aby określić, czy typ i wersja bieżącej przeglądarki obsługuje określoną wersję języka JavaScript. Możesz też użyć obiektu HttpBrowserCapabilities , aby określić, czy żądanie pochodzi z urządzenia przenośnego.

Obiekt HttpBrowserCapabilities jest napędzany przez zestaw plików definicji przeglądarki. Te pliki zawierają informacje o możliwościach określonych przeglądarek. W ASP.NET 4 te pliki definicji przeglądarki zostały zaktualizowane tak, aby zawierały informacje o niedawno wprowadzonych przeglądarkach i urządzeniach, takich jak Google Chrome, Research in Motion BlackBerry smartphones i Apple iPhone.

Na poniższej liście przedstawiono nowe pliki definicji przeglądarki:

blackberry.browser
chrome.browser
Default.browser
firefox.browser
gateway.browser
generic.browser
ie.browser
iemobile.browser
iphone.browser
opera.browser
safari.browser

Korzystanie z dostawców funkcji przeglądarki

W ASP.NET wersji 3.5 z dodatkiem Service Pack 1 można zdefiniować możliwości przeglądarki na następujące sposoby:

Na poziomie komputera utworzysz lub zaktualizujesz .browser plik XML w następującym folderze:

\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

Po zdefiniowaniu możliwości przeglądarki uruchom następujące polecenie w wierszu polecenia programu Visual Studio, aby ponownie skompilować zestaw funkcji przeglądarki i dodać go do usługi GAC:
```
aspnet_regbrowsers.exe -I c
```
W przypadku pojedynczej aplikacji należy utworzyć .browser plik w folderze aplikacji App_Browsers .

Te podejścia wymagają zmiany plików XML, a w przypadku zmian na poziomie komputera należy ponownie uruchomić aplikację po uruchomieniu procesu aspnet_regbrowsers.exe.

ASP.NET 4 zawiera funkcję określaną jako dostawcy funkcji przeglądarki. Jak sugeruje nazwa, pozwala to utworzyć dostawcę, który z kolei umożliwia korzystanie z własnego kodu w celu określenia możliwości przeglądarki.

W praktyce deweloperzy często nie definiują niestandardowych możliwości przeglądarki. Pliki przeglądarki są trudne do zaktualizowania, proces ich aktualizowania jest dość skomplikowany, a składnia XML dla .browser plików może być złożona do użycia i zdefiniowania. Co ułatwiłoby ten proces, gdyby istniała powszechna składnia definicji przeglądarki lub baza danych zawierająca aktualne definicje przeglądarki, a nawet usługa sieci Web dla takiej bazy danych. Nowa funkcja dostawców funkcji przeglądarki sprawia, że te scenariusze są możliwe i praktyczne dla deweloperów innych firm.

Istnieją dwa główne podejścia do korzystania z nowej funkcji dostawcy funkcji przeglądarki ASP.NET 4: rozszerzanie funkcji definicji przeglądarki ASP.NET lub całkowite zastąpienie jej. W poniższych sekcjach opisano najpierw, jak zastąpić funkcjonalność, a następnie jak ją rozszerzyć.

Zastępowanie funkcji ASP.NET Browser

Aby całkowicie zastąpić funkcje definicji ASP.NET przeglądarki, wykonaj następujące kroki:

Utwórz klasę dostawcy, która pochodzi z klasy HttpCapabilitiesProvider i zastępuje metodę GetBrowserCapabilities , jak w poniższym przykładzie:

public class CustomProvider : HttpCapabilitiesProvider 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities(); 
        Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase); 
        values[String.Empty] = request.UserAgent; 
        values["browser"] = "MyCustomBrowser"; 
        browserCaps.Capabilities = values; 
        return browserCaps;
    } 
}

Kod w tym przykładzie tworzy nowy obiekt HttpBrowserCapabilities , określając tylko funkcję o nazwie browser i ustawiając tę funkcję na MyCustomBrowser.

Zarejestruj dostawcę w aplikacji.

Aby użyć dostawcy z aplikacją, należy dodać atrybut dostawcy do sekcji browserCaps w plikachWeb.config lub Machine.config . (Atrybuty dostawcy można również zdefiniować w elemecie lokalizacji dla określonych katalogów w aplikacji, na przykład w folderze dla określonego urządzenia przenośnego). W poniższym przykładzie pokazano, jak ustawić atrybut dostawcy w pliku konfiguracji:
```
<system.web> 
<browserCaps provider="ClassLibrary2.CustomProvider, ClassLibrary2, 
  Version=1.0.0.0, Culture=neutral" /> 
</system.web>
```
Innym sposobem zarejestrowania nowej definicji możliwości przeglądarki jest użycie kodu, jak pokazano w poniższym przykładzie:
```
void Application_Start(object sender, EventArgs e) 
{ 
    HttpCapabilitiesBase.BrowserCapabilitiesProvider =
    new ClassLibrary2.CustomProvider();
    // ... 
 }
```
Ten kod musi zostać uruchomiony w Application_Start zdarzenia Global.asax pliku. Wszelkie zmiany w klasie BrowserCapabilitiesProvider muszą wystąpić przed wykonaniem kodu w aplikacji, aby upewnić się, że pamięć podręczna pozostaje w prawidłowym stanie dla rozpoznanego obiektu HttpCapabilitiesBase .

Buforowanie obiektu HttpBrowserCapabilities

Powyższy przykład ma jeden problem, który polega na tym, że kod będzie uruchamiany za każdym razem, gdy dostawca niestandardowy jest wywoływany w celu pobrania obiektu HttpBrowserCapabilities . Może się to zdarzyć wielokrotnie podczas każdego żądania. W tym przykładzie kod dostawcy nie robi zbyt wiele. Jeśli jednak kod u dostawcy niestandardowego wykonuje znaczną pracę, aby uzyskać obiekt HttpBrowserCapabilities , może to mieć wpływ na wydajność. Aby temu zapobiec, można buforować obiekt HttpBrowserCapabilities . Wykonaj następujące kroki:

Utwórz klasę, która pochodzi z obiektu HttpCapabilitiesProvider, podobnie jak w poniższym przykładzie:

public class CustomProvider : HttpCapabilitiesProvider 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        string cacheKey = BuildCacheKey(); 
        int cacheTime = GetCacheTime(); 
        HttpBrowserCapabilities browserCaps = 
        HttpContext.Current.Cache[cacheKey] as 
        HttpBrowserCapabilities; 
        if (browserCaps == null) 
        { 
            HttpBrowserCapabilities browserCaps = new 
            HttpBrowserCapabilities(); 
            Hashtable values = new Hashtable(180, 
            StringComparer.OrdinalIgnoreCase); 
            values[String.Empty] = request.UserAgent; 
            values["browser"] = "MyCustomBrowser"; 
            browserCaps.Capabilities = values; 
            HttpContext.Current.Cache.Insert(cacheKey, 
            browserCaps, null, DateTime.MaxValue, 
            TimeSpan.FromSeconds(cacheTime));
        } 
        return browserCaps; 
    } 
}

W tym przykładzie kod generuje klucz pamięci podręcznej przez wywołanie niestandardowej metody BuildCacheKey i pobiera czas buforowania przez wywołanie niestandardowej metody GetCacheTime. Następnie kod dodaje rozpoznany obiekt HttpBrowserCapabilities do pamięci podręcznej. Obiekt można pobrać z pamięci podręcznej i ponownie użyć do kolejnych żądań, które korzystają z dostawcy niestandardowego.

Zarejestruj dostawcę w aplikacji zgodnie z opisem w poprzedniej procedurze.

Rozszerzanie funkcji przeglądarki ASP.NET

W poprzedniej sekcji opisano sposób tworzenia nowego obiektu HttpBrowserCapabilities w ASP.NET 4. Możesz również rozszerzyć funkcje przeglądarki ASP.NET, dodając nowe definicje funkcji przeglądarki do tych, które są już w ASP.NET. Można to zrobić bez użycia definicji przeglądarki XML. Poniższa procedura pokazuje, jak.

Utwórz klasę, która pochodzi z klasy HttpCapabilitiesEvaluator i zastępuje metodę GetBrowserCapabilities , jak pokazano w poniższym przykładzie:
```
public class CustomProvider : HttpCapabilitiesEvaluator 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        HttpBrowserCapabilities browserCaps = 
        base.GetHttpBrowserCapabilities(request);
        if (browserCaps.Browser == "Unknown") 
        { 
            browserCaps = MyBrowserCapabilitiesEvaulator(request); 
        } 
        return browserCaps; 
    } 
}
```
Ten kod najpierw używa funkcji przeglądarki ASP.NET, aby spróbować zidentyfikować przeglądarkę. Jeśli jednak żadna przeglądarka nie jest identyfikowana na podstawie informacji zdefiniowanych w żądaniu (czyli jeśli właściwość Browser obiektu HttpBrowserCapabilities jest ciągiem "Nieznany"), kod wywołuje dostawcę niestandardowego (MyBrowserCapabilitiesEvaluator), aby zidentyfikować przeglądarkę.
Zarejestruj dostawcę w aplikacji zgodnie z opisem w poprzednim przykładzie.

Rozszerzanie funkcji przeglądarki przez dodanie nowych możliwości do istniejących definicji funkcji

Oprócz tworzenia niestandardowego dostawcy definicji przeglądarki i dynamicznego tworzenia nowych definicji przeglądarki można rozszerzyć istniejące definicje przeglądarki z dodatkowymi możliwościami. Dzięki temu można użyć definicji zbliżonej do tego, co chcesz, ale brakuje tylko kilku możliwości. W tym celu wykonaj następujące czynności.

Utwórz klasę, która pochodzi z klasy HttpCapabilitiesEvaluator i zastępuje metodę GetBrowserCapabilities , jak pokazano w poniższym przykładzie:
```
public class CustomProvider : HttpCapabilitiesEvaluator 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        HttpBrowserCapabilities browserCaps = 
          base.GetHttpBrowserCapabilities(request); 
        if (browserCaps.Browser == "Unknown") 
        { 
            browserCaps = MyBrowserCapabilitiesEvaulator(request); 
        } 
        return browserCaps; 
    }
}
```
Przykładowy kod rozszerza istniejącą klasę ASP.NET HttpCapabilitiesEvaluator i pobiera obiekt HttpBrowserCapabilities zgodny z bieżącą definicją żądania przy użyciu następującego kodu:
```
HttpBrowserCapabilities browserCaps = 
    base.GetHttpBrowserCapabilities(request);
```
Kod może następnie dodać lub zmodyfikować możliwość dla tej przeglądarki. Istnieją dwa sposoby określania nowej możliwości przeglądarki:
- Dodaj parę klucz/wartość do obiektu IDictionary uwidocznionego przez właściwość Capabilities obiektu HttpCapabilitiesBase . W poprzednim przykładzie kod dodaje możliwość o nazwie MultiTouch z wartością true.
- Ustaw istniejące właściwości obiektu HttpCapabilitiesBase . W poprzednim przykładzie kod ustawia właściwość Frame na true. Ta właściwość jest po prostu akcesorem obiektu IDictionary , który jest uwidoczniony przez właściwość Capabilities .
  
  Uwaga
  
  Uwaga Ten model ma zastosowanie do dowolnej właściwości HttpBrowserCapabilities, w tym kart sterujących.
Zarejestruj dostawcę w aplikacji zgodnie z opisem we wcześniejszej procedurze.

Routing w ASP.NET 4

ASP.NET 4 dodaje wbudowaną obsługę używania routingu z Web Forms. Routing umożliwia skonfigurowanie aplikacji w celu akceptowania adresów URL żądań, które nie są mapowanie na pliki fizyczne. Zamiast tego możesz użyć routingu, aby zdefiniować adresy URL, które są istotne dla użytkowników i które mogą pomóc w optymalizacji wyszukiwarki (SEO) dla aplikacji. Na przykład adres URL strony, która wyświetla kategorie produktów w istniejącej aplikacji, może wyglądać podobnie do następującego przykładu:

http://website/products.aspx?categoryid=12

Za pomocą routingu można skonfigurować aplikację tak, aby akceptowała następujący adres URL w celu renderowania tych samych informacji:

http://website/products/software

Routing jest dostępny od ASP.NET 3.5 SP1. (Aby zapoznać się z przykładem użycia routingu w programie ASP.NET 3.5 SP1, zobacz wpis Korzystanie z routingu za pomocą funkcji WebForms na blogu Phila Haacka). Jednak ASP.NET 4 zawiera niektóre funkcje, które ułatwiają korzystanie z routingu, w tym następujące:

Klasa PageRouteHandler , która jest prostą procedurą obsługi HTTP używaną podczas definiowania tras. Klasa przekazuje dane do strony, do którą jest kierowane żądanie.
Nowe właściwości HttpRequest.RequestContext i Page.RouteData (czyli serwer proxy obiektu HttpRequest.RequestContext.RouteData ). Te właściwości ułatwiają dostęp do informacji przekazywanych z trasy.
Następujące nowe konstruktory wyrażeń zdefiniowane w programie System.Web.Compilation.RouteUrlExpressionBuilder i System.Web.Compilation.RouteValueExpressionBuilder:
RouteUrl, który zapewnia prosty sposób tworzenia adresu URL odpowiadającego adresowi URL trasy w ramach kontroli serwera ASP.NET.
RouteValue, która zapewnia prosty sposób wyodrębniania informacji z obiektu RouteContext .
Klasa RouteParameter , która ułatwia przekazywanie danych zawartych w obiekcie RouteContext do zapytania dla kontrolki źródła danych (podobnie jak FormParameter).

Routing dla stron Web Forms

W poniższym przykładzie pokazano, jak zdefiniować trasę Web Forms przy użyciu nowej metody MapPageRoute klasy Route:

public class Global : System.Web.HttpApplication 
{ 
    void Application_Start(object sender, EventArgs e) 
    { 
        RouteTable.Routes.MapPageRoute("SearchRoute", 
          "search/{searchterm}", "~/search.aspx"); 
        RouteTable.Routes.MapPageRoute("UserRoute", 
          "users/{username}", "~/users.aspx"); 
    } 
}

ASP.NET 4 wprowadza metodę MapPageRoute . Poniższy przykład jest odpowiednikiem definicji usługi SearchRoute pokazanej w poprzednim przykładzie, ale używa klasy PageRouteHandler .

RouteTable.Routes.Add("SearchRoute", new Route("search/{searchterm}", 
  new PageRouteHandler("~/search.aspx")));

Kod w przykładzie mapuje trasę na stronę fizyczną (w pierwszej trasie na ~/search.aspx). Pierwsza definicja trasy określa również, że parametr o nazwie searchterm powinien zostać wyodrębniony z adresu URL i przekazany do strony.

Metoda MapPageRoute obsługuje następujące przeciążenia metody:

MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess)
MapPageRoute(ciąg routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary defaults)
MapPageRoute(ciąg routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary defaults, RouteValueDictionary ograniczenia)

Parametr checkPhysicalUrlAccess określa, czy trasa powinna sprawdzić uprawnienia zabezpieczeń dla strony fizycznej kierowanej do (w tym przypadku search.aspx) i uprawnienia do przychodzącego adresu URL (w tym przypadku search/{searchterm}). Jeśli wartość checkPhysicalUrlAccess ma wartość false, zostaną sprawdzone tylko uprawnienia przychodzącego adresu URL. Te uprawnienia są definiowane w Web.config pliku przy użyciu ustawień, takich jak:

<configuration> 
  <location path="search.aspx"> 
    <system.web> 
      <authorization> 
        <allow roles="admin"/> 
        <deny users="*"/> 
      </authorization> 
    </system.web> 
  </location> 
  <location path="search"> 
    <system.web> 
      <authorization> 
        <allow users="*"/> 
      </authorization> 
    </system.web> 
  </location> 

</configuration>

W przykładowej konfiguracji dostęp jest odrzucany na stronie search.aspx fizycznej dla wszystkich użytkowników z wyjątkiem tych, którzy znajdują się w roli administratora. Gdy parametr checkPhysicalUrlAccess jest ustawiony na wartość true (która jest jego wartością domyślną), tylko użytkownicy administracyjni mogą uzyskiwać dostęp do adresu URL /search/{searchterm}, ponieważ wyszukiwanie strony fizycznej.aspx jest ograniczone do użytkowników w tej roli. Jeśli właściwość checkPhysicalUrlAccess jest ustawiona na wartość false , a witryna jest skonfigurowana tak jak pokazano w poprzednim przykładzie, wszyscy uwierzytelnieni użytkownicy mogą uzyskiwać dostęp do adresu URL /search/{searchterm}.

Odczytywanie informacji o routingu na stronie Web Forms

W kodzie strony fizycznej Web Forms można uzyskać dostęp do informacji wyodrębnionych z adresu URL (lub innych informacji dodanych do obiektu RouteData) przy użyciu dwóch nowych właściwości: HttpRequest.RequestContext i Page.RouteData. (Page.RouteData opakowuje httpRequest.RequestContext.RouteData). W poniższym przykładzie pokazano, jak używać metody Page.RouteData.

protected void Page_Load(object sender, EventArgs e) 
{ 
    string searchterm = Page.RouteData.Values["searchterm"] as string; 
    label1.Text = searchterm; 
}

Kod wyodrębnia wartość, która została przekazana dla parametru searchterm, zgodnie z definicją we wcześniejszej przykładowej trasie. Rozważ następujący adres URL żądania:

http://localhost/search/scott/

Po wysłaniu tego żądania wyraz "scott" zostanie renderowany na search.aspx stronie.

Uzyskiwanie dostępu do informacji o routingu w adiustacji

Metoda opisana w poprzedniej sekcji pokazuje, jak pobrać dane trasy w kodzie na stronie Web Forms. Możesz również użyć wyrażeń w znacznikach, które zapewniają dostęp do tych samych informacji. Konstruktory wyrażeń to zaawansowany i elegancki sposób pracy z kodem deklaratywnym. (Aby uzyskać więcej informacji, zobacz wpis Express Yourself With Custom Expression Builders na blogu Phila Haacka).

ASP.NET 4 zawiera dwóch nowych konstruktorów wyrażeń na potrzeby routingu Web Forms. W poniższym przykładzie pokazano, jak ich używać.

<asp:HyperLink ID="HyperLink1" runat="server" 
  NavigateUrl="<%$RouteUrl:SearchTerm=scott%>">Search for Scott</asp:HyperLink>

W tym przykładzie wyrażenie RouteUrl służy do definiowania adresu URL opartego na parametrze trasy. Pozwala to zaoszczędzić na konieczności zapisania pełnego adresu URL w znaczniku i umożliwia późniejsze zmianę struktury adresu URL bez konieczności zmiany tego linku.

Na podstawie zdefiniowanej wcześniej trasy ten znacznik generuje następujący adres URL:

http://localhost/search/scott

ASP.NET automatycznie sprawdza poprawną trasę (czyli generuje prawidłowy adres URL) na podstawie parametrów wejściowych. W wyrażeniu można również uwzględnić nazwę trasy, która umożliwia określenie trasy do użycia.

W poniższym przykładzie pokazano, jak używać wyrażenia RouteValue .

<asp:Label ID="Label1" runat="server" Text="<%$RouteValue:SearchTerm%>" />

Po uruchomieniu strony zawierającej tę kontrolkę wartość "scott" jest wyświetlana w etykiecie.

Wyrażenie RouteValue ułatwia używanie danych tras w znacznikach i unika pracy z bardziej złożoną składnią Page.RouteData["x"] w znacznikach.

Używanie danych trasy dla parametrów kontroli źródła danych

Klasa RouteParameter pozwala określić dane trasy jako wartość parametru dla zapytań w kontrolce źródła danych. Działa podobnie jak klasa, jak pokazano w poniższym przykładzie:

<asp:sqldatasource id="SqlDataSource1" runat="server" 
    connectionstring="<%$ ConnectionStrings:MyNorthwind %>" 
    selectcommand="SELECT CompanyName,ShipperID FROM Shippers where 
      CompanyName=@companyname" 
  <selectparameters> 
    <asp:routeparameter name="companyname" RouteKey="searchterm" /> 
  </selectparameters> 

</asp:sqldatasource>

W takim przypadku wartość parametru trasy searchterm będzie używana dla parametru @companyname w instrukcji Select .

Ustawianie identyfikatorów klientów

Nowa właściwość ClientIDMode rozwiązuje długotrwały problem w ASP.NET, a mianowicie sposób tworzenia atrybutu id dla elementów renderowanych. Znajomość atrybutu id dla renderowanych elementów jest ważna, jeśli aplikacja zawiera skrypt klienta, który odwołuje się do tych elementów.

Atrybut id w kodzie HTML renderowanym dla kontrolek serwera sieci Web jest generowany na podstawie właściwości ClientID kontrolki. Do ASP.NET 4 algorytm generowania atrybutu id z właściwości ClientID został połączony kontener nazewnictwa (jeśli istnieje) z identyfikatorem, a w przypadku powtarzających się kontrolek (jak w kontrolkach danych) do dodania prefiksu i liczby sekwencyjnej. Chociaż zawsze zagwarantowano, że identyfikatory kontrolek na stronie są unikatowe, algorytm spowodował identyfikatory kontrolek, które nie były przewidywalne i dlatego trudno było odwoływać się do skryptu klienta.

Nowa właściwość ClientIDMode umożliwia dokładniejsze określenie sposobu generowania identyfikatora klienta dla kontrolek. Można ustawić właściwość ClientIDMode dla dowolnej kontrolki, w tym dla strony. Możliwe ustawienia są następujące:

AutoID — jest to odpowiednik algorytmu generowania wartości właściwości ClientID , które były używane we wcześniejszych wersjach ASP.NET.
Statyczny — określa, że wartość ClientID będzie taka sama jak identyfikator bez łączenia identyfikatorów kontenerów nazewnictwa nadrzędnego. Może to być przydatne w kontrolkach użytkownika sieci Web. Ponieważ kontrolka użytkownika sieci Web może znajdować się na różnych stronach i w różnych kontrolkach kontenera, może być trudno napisać skrypt klienta dla kontrolek używających algorytmu AutoID , ponieważ nie można przewidzieć wartości identyfikatorów.
Przewidywalne — ta opcja jest używana głównie w kontrolkach danych, które używają powtarzających się szablonów. Łączy właściwości identyfikatora kontenerów nazewnictwa kontrolki, ale wygenerowane wartości ClientID nie zawierają ciągów, takich jak "ctlxxx". To ustawienie działa w połączeniu z właściwością ClientIDRowSuffix kontrolki. Właściwość ClientIDRowSuffix jest ustawiana na nazwę pola danych, a wartość tego pola jest używana jako sufiks wygenerowanej wartości ClientID . Zazwyczaj należy użyć klucza podstawowego rekordu danych jako wartości ClientIDRowSuffix .
Dziedzicz — to ustawienie jest domyślnym zachowaniem kontrolek; Określa, że generowanie identyfikatora kontrolki jest takie samo jak jego element nadrzędny.

Właściwość ClientIDMode można ustawić na poziomie strony. Definiuje domyślną wartość ClientIDMode dla wszystkich kontrolek na bieżącej stronie.

Domyślna wartość ClientIDMode na poziomie strony to AutoID, a domyślna wartość ClientIDMode na poziomie kontrolki to Dziedzicz. W związku z tym, jeśli ta właściwość nie zostanie ustawiona w dowolnym miejscu w kodzie, wszystkie kontrolki będą domyślnie stosowane do algorytmu AutoID .

Wartość na poziomie strony należy ustawić w dyrektywie @ Page , jak pokazano w poniższym przykładzie:

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeFile="Default.aspx.cs" 
  Inherits="_Default" 
  ClientIDMode="Predictable" %>

Można również ustawić wartość ClientIDMode w pliku konfiguracji na poziomie komputera (komputera) lub na poziomie aplikacji. Definiuje domyślne ustawienie ClientIDMode dla wszystkich kontrolek na wszystkich stronach w aplikacji. Jeśli ustawisz wartość na poziomie komputera, definiuje domyślne ustawienie ClientIDMode dla wszystkich witryn sieci Web na tym komputerze. W poniższym przykładzie przedstawiono ustawienie ClientIDMode w pliku konfiguracji:

<system.web> 
  <pages clientIDMode="Predictable"></pages> 
</system.web>

Jak wspomniano wcześniej, wartość właściwości ClientID pochodzi z kontenera nazewnictwa dla elementu nadrzędnego kontrolki. W niektórych scenariuszach, takich jak w przypadku korzystania ze stron wzorcowych, kontrolki mogą zawierać identyfikatory, takie jak te w następującym renderowanym kodzie HTML:

<div id="ctl00_ContentPlaceHolder1_ParentPanel"> 
  <div id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1"> 
    <input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1" 
      type="text" value="Hello!" 
      id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1" /> 
</div>

Mimo że element wejściowy wyświetlany w adiustacji (z kontrolki TextBox ) to tylko dwa kontenery nazewnictwa głęboko na stronie (zagnieżdżone kontrolki ContentPlaceholder ), ze względu na sposób przetwarzania stron wzorcowych wynik końcowy jest identyfikatorem kontrolki, tak jak poniżej:

ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1

Ten identyfikator ma gwarancję unikatowości na stronie, ale jest niepotrzebnie długi dla większości celów. Załóżmy, że chcesz zmniejszyć długość renderowanego identyfikatora i mieć większą kontrolę nad sposobem generowania identyfikatora. (Na przykład chcesz wyeliminować prefiksy "ctlxxx". Najprostszym sposobem osiągnięcia tego celu jest ustawienie właściwości ClientIDMode , jak pokazano w poniższym przykładzie:

<tc:NamingPanel runat="server" ID="ParentPanel" ClientIDMode="Static"> 
  <tc:NamingPanel runat="server" ID="NamingPanel1" ClientIDMode="Predictable"> 
    <asp:TextBox ID="TextBox1" runat="server" Text="Hello!"></asp:TextBox> 
  </tc:NamingPanel> 

</tc:NamingPanel>

W tym przykładzie właściwość ClientIDMode jest ustawiona na Static dla najbardziej zewnętrznego elementu NamingPanel i ustawiona na przewidywalną dla wewnętrznego elementu NamingControl . Te ustawienia powodują następujący znacznik (reszta strony i zakłada się, że strona wzorcowa jest taka sama jak w poprzednim przykładzie):

<div id="ParentPanel"> 
  <div id="ParentPanel_NamingPanel1"> 
    <input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1" 
        type="text" value="Hello!" id="ParentPanel_NamingPanel1_TextBox1" /> 
</div>

Ustawienie Statyczne ma wpływ na zresetowanie hierarchii nazewnictwa dla wszystkich kontrolek wewnątrz najbardziej zewnętrznego elementu NamingPanel oraz wyeliminowanie identyfikatorów ContentPlaceHolder i MasterPage z wygenerowanego identyfikatora. (Nie ma to wpływu na atrybut nazwy renderowanych elementów, więc normalne funkcje ASP.NET są zachowywane dla zdarzeń, stanu widoku itd.) Efektem ubocznym zresetowania hierarchii nazewnictwa jest to, że nawet jeśli przeniesiesz znaczniki dla elementów NamingPanel do innej kontrolki ContentPlaceholder , renderowane identyfikatory klienta pozostaną takie same.

Uwaga

Uwaga Do Ciebie należy upewnić się, że renderowane identyfikatory kontrolek są unikatowe. Jeśli tak nie jest, może to przerwać wszelkie funkcje, które wymagają unikatowych identyfikatorów dla poszczególnych elementów HTML, takich jak dokument klienta.getElementById .

Tworzenie przewidywalnych identyfikatorów klientów w kontrolkach Data-Bound

Wartości ClientID generowane dla kontrolek w kontrolce listy powiązanej z danymi przez starszy algorytm mogą być długie i nie są naprawdę przewidywalne. Funkcja ClientIDMode może pomóc w większej kontroli nad sposobem generowania tych identyfikatorów.

Znaczniki w poniższym przykładzie zawierają kontrolkę ListView :

<asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1" 
    OnSelectedIndexChanged="ListView1_SelectedIndexChanged" 
    ClientIDMode="Predictable" 
    RowClientIDRowSuffix="ProductID"> 
</asp:ListView>

W poprzednim przykładzie właściwości ClientIDMode i RowClientIDRowSuffix są ustawiane w adiustacji. Właściwość ClientIDRowSuffix może być używana tylko w kontrolkach powiązanych z danymi, a jej zachowanie różni się w zależności od używanej kontrolki. Różnice są następujące:

Kontrolka GridView — można określić nazwę co najmniej jednej kolumny w źródle danych, które są łączone w czasie wykonywania w celu utworzenia identyfikatorów klienta. Jeśli na przykład ustawisz wartość RowClientIDRowSuffix na "ProductName, ProductId", identyfikatory kontrolek dla renderowanych elementów będą miały format podobny do następującego:

rootPanel_GridView1_ProductNameLabel_Chai_1

Kontrolka ListView — można określić jedną kolumnę w źródle danych dołączonym do identyfikatora klienta. Jeśli na przykład ustawisz wartość ClientIDRowSuffix na "ProductName", renderowane identyfikatory kontrolek będą miały format podobny do następującego:
```
rootPanel_ListView1_ProductNameLabel_1
```
W takim przypadku końcowy 1 pochodzi z identyfikatora produktu bieżącego elementu danych.
Kontrolka repeater — ta kontrolka nie obsługuje właściwości ClientIDRowSuffix. W kontrolce Repeater jest używany indeks bieżącego wiersza. W przypadku używania elementu ClientIDMode="Predictable" z kontrolką Repeater identyfikatory klientów są generowane w następującym formacie:
```
Repeater1_ProductNameLabel_0
```
Końcowy 0 to indeks bieżącego wiersza.

Kontrolki FormView i DetailsView nie wyświetlają wielu wierszy, więc nie obsługują właściwości ClientIDRowSuffix .

Utrwalanie zaznaczenia wiersza w kontrolkach danych

Kontrolki GridView i ListView umożliwiają użytkownikom wybranie wiersza. W poprzednich wersjach ASP.NET wybór został oparty na indeksie wierszy na stronie. Jeśli na przykład wybierzesz trzeci element na stronie 1, a następnie przejdziesz do strony 2, zostanie wybrany trzeci element na tej stronie.

Utrwalone zaznaczenie było początkowo obsługiwane tylko w projektach dynamicznych danych w .NET Framework 3.5 z dodatkiem SP1. Po włączeniu tej funkcji bieżący wybrany element jest oparty na kluczu danych dla elementu. Oznacza to, że jeśli wybierzesz trzeci wiersz na stronie 1 i przejdziesz do strony 2, nic nie zostanie wybrane na stronie 2. Po powrocie do strony 1 trzeci wiersz jest nadal zaznaczony. Utrwalone zaznaczenie jest teraz obsługiwane dla kontrolek GridView i ListView we wszystkich projektach przy użyciu właściwości EnablePersistedSelection , jak pokazano w poniższym przykładzie:

<asp:GridView id="GridView2" runat="server" EnablePersistedSelection="true"> 
</asp:GridView>

kontrolka wykresu ASP.NET

Kontrolka wykresu ASP.NET rozszerza oferty wizualizacji danych w .NET Framework. Za pomocą kontrolki Wykres można tworzyć strony ASP.NET, które mają intuicyjne i wizualnie atrakcyjne wykresy do złożonej analizy statystycznej lub finansowej. Kontrolka wykresu ASP.NET została wprowadzona jako dodatek do wersji .NET Framework w wersji 3.5 SP1 i jest częścią wersji .NET Framework 4.

Kontrolka zawiera następujące funkcje:

35 odrębnych typów wykresów.
Nieograniczona liczba obszarów wykresu, tytułów, legend i adnotacji.
Wiele różnych ustawień wyglądu dla wszystkich elementów wykresu.
Obsługa 3-W dla większości typów wykresów.
Inteligentne etykiety danych, które mogą automatycznie mieścić się wokół punktów danych.
Linie rozłożone, podziały skali i skalowanie logarytmyczne.
Ponad 50 formuł finansowych i statystycznych na potrzeby analizy i transformacji danych.
Proste powiązanie i manipulowanie danymi wykresu.
Obsługa typowych formatów danych, takich jak daty, godziny i waluta.
Obsługa interakcyjności i dostosowywania sterowanego zdarzeniami, w tym zdarzeń kliknięcia klienta przy użyciu technologii Ajax.
Zarządzanie stanem.
Przesyłanie strumieniowe danych binarnych.

Na poniższych ilustracjach przedstawiono przykłady wykresów finansowych generowanych przez kontrolkę wykresu ASP.NET.

Cztery przykładowe wykresy finansowe generowane przez kontrolkę wykresu ASP.NET.

Rysunek 2. Przykłady kontrolek wykresu ASP.NET

Aby uzyskać więcej przykładów używania kontrolki wykresu ASP.NET, pobierz przykładowy kod na stronie Samples Environment for Microsoft Chart Controls (Środowisko przykładów dla kontrolek wykresu microsoft ) w witrynie sieci Web MSDN. Więcej przykładów zawartości społeczności można znaleźć na forum sterowania wykresami.

Dodawanie kontrolki wykresu do strony ASP.NET

W poniższym przykładzie pokazano, jak dodać kontrolkę Wykres do strony ASP.NET przy użyciu znaczników. W tym przykładzie kontrolka Wykres tworzy wykres kolumnowy dla statycznych punktów danych.

<asp:Chart ID="Chart1" runat="server"> 
  <Series> 
    <asp:Series Name="Series1" ChartType="Column"> 
      <Points> 
        <asp:DataPoint AxisLabel="Product A" YValues="345"/> 
        <asp:DataPoint AxisLabel="Product B" YValues="456"/> 
        <asp:DataPoint AxisLabel="Product C" YValues="125"/> 
        <asp:DataPoint AxisLabel="Product D" YValues="957"/> &

      lt;/Points> 
    </asp:Series> 
  </Series> 
  <ChartAreas> 
    <asp:ChartArea Name="ChartArea1"> 
      <AxisY IsLogarithmic="True" /> 
    </asp:ChartArea> 
  </ChartAreas> 
  <Legends> 
    <asp:Legend Name="Legend1" Title="Product Sales" /> 
  </Legends> 

</asp:Chart>

Korzystanie z wykresów 3-W

Kontrolka Wykres zawiera kolekcję ChartAreas , która może zawierać obiekty ChartArea definiujące cechy obszarów wykresu. Aby na przykład użyć 3-W dla obszaru wykresu, użyj właściwości Area3DStyle , jak w poniższym przykładzie:

<asp:ChartArea Name="ChartArea1"> 
  <area3dstyle 
      Rotation="10" 
      Perspective="10" 
      Enable3D="True" 
      Inclination="15" 
      IsRightAngleAxes="False" 
      WallWidth="0" 
      IsClustered="False" /> 
      
  <%-- Additional markup here --%> 
</asp:ChartArea>

Na poniższej ilustracji przedstawiono wykres 3-W z czterema seriami typu wykresu słupkowego .

3-wymiarowy wykres słupkowy przedstawiający cztery serie typu wykresu słupkowego.

Rysunek 3. Wykres słupkowy 3-W

Używanie podziałów skali i skali logarytmów

Skalowanie podziałów i skali logarytmiczne to dwa dodatkowe sposoby dodawania wyrafinowania do wykresu. Te funkcje są specyficzne dla każdej osi w obszarze wykresu. Aby na przykład użyć tych funkcji na podstawowej osi Y obszaru wykresu, użyj właściwości AxisY.IsLogarithmic i ScaleBreakStyle w obiekcie ChartArea . Poniższy fragment kodu pokazuje, jak używać podziałów skalowania na podstawowej osi Y.

<asp:ChartArea Name="ChartArea1">

  <axisy>

    <ScaleBreakStyle 
        BreakLineStyle="Wave" 
        CollapsibleSpaceThreshold="40" 
        Enabled="True" />
  </axisy>

<%-- Additional markup here --%>
</asp:ChartArea>

Na poniższej ilustracji przedstawiono oś Y z włączonymi podziałami skali.

Wykres słupkowy przedstawiający oś Y z włączonymi podziałami skalowania.

Rysunek 4. Podziały skalowania

Filtrowanie danych za pomocą kontrolki QueryExtender

Bardzo typowym zadaniem deweloperów tworzących strony internetowe oparte na danych jest filtrowanie danych. Tradycyjnie odbywa się to przez utworzenie klauzul Where w kontrolkach źródła danych. Takie podejście może być skomplikowane, a w niektórych przypadkach składnia Where nie pozwala korzystać z pełnej funkcjonalności bazowej bazy danych.

Aby ułatwić filtrowanie, w ASP.NET 4 dodano nową kontrolkę QueryExtender . Tę kontrolkę można dodać do kontrolek EntityDataSource lub LinqDataSource w celu filtrowania danych zwracanych przez te kontrolki. Ponieważ kontrolka QueryExtender opiera się na LINQ, filtr jest stosowany na serwerze bazy danych przed wysłaniem danych do strony, co powoduje bardzo wydajne operacje.

Kontrolka QueryExtender obsługuje różne opcje filtrowania. W poniższych sekcjach opisano te opcje i przedstawiono przykłady sposobu ich używania.

Wyszukaj

W przypadku opcji wyszukiwania kontrolka QueryExtender wykonuje wyszukiwanie w określonych polach. W poniższym przykładzie kontrolka używa tekstu wprowadzonego w kontrolce TextBoxSearch i wyszukuje jego zawartość w kolumnach i Supplier.CompanyName w ProductName danych zwracanych z kontrolki LinqDataSource.

<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:SearchExpression DataFields="ProductName, Supplier.CompanyName" 
      SearchType="StartsWith"> 
    <asp:ControlParameter ControlID="TextBoxSearch" /> 
  </asp:SearchExpression> 
</asp:QueryExtender>

Zakres

Opcja zakresu jest podobna do opcji wyszukiwania, ale określa parę wartości do zdefiniowania zakresu. W poniższym przykładzie kontrolka QueryExtender przeszukuje kolumnę UnitPrice w danych zwróconych z kontrolki LinqDataSource . Zakres jest odczytywany z kontrolek TextBoxFrom i TextBoxTo na stronie.

<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:RangeExpression DataField="UnitPrice" MinType="Inclusive" 
      MaxType="Inclusive"> 
    <asp:ControlParameter ControlID="TextBoxFrom" /> 
    <asp:ControlParameter ControlID="TexBoxTo" /> 
  </asp:RangeExpression> 

</asp:QueryExtender>

Propertyexpression

Opcja wyrażenia właściwości umożliwia zdefiniowanie porównania z wartością właściwości. Jeśli wyrażenie zwróci wartość true, zwracane są badane dane. W poniższym przykładzie kontrolka QueryExtender filtruje dane, porównując dane w Discontinued kolumnie z wartością kontrolki CheckBoxDiscontinued na stronie.

<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
   <asp:PropertyExpression>
      <asp:ControlParameter ControlID="CheckBoxDiscontinued" Name="Discontinued" />
   </asp:PropertyExpression>
</asp:QueryExtender>

Customexpression

Na koniec możesz określić wyrażenie niestandardowe do użycia z kontrolką QueryExtender . Ta opcja umożliwia wywołanie funkcji na stronie definiującej niestandardową logikę filtru. W poniższym przykładzie pokazano, jak deklaratywnie określić wyrażenie niestandardowe w kontrolce QueryExtender .

<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:CustomExpression OnQuerying="FilterProducts" /> 
</asp:QueryExtender>

Poniższy przykład przedstawia funkcję niestandardową wywoływaną przez kontrolkę QueryExtender . W tym przypadku zamiast używać zapytania bazy danych zawierającego klauzulę Where , kod używa zapytania LINQ do filtrowania danych.

protected void FilterProducts(object sender, CustomExpressionEventArgs e) 
{ 
    e.Query = from p in e.Query.Cast() 
      where p.UnitPrice >= 10 
      select p; 
}

W tych przykładach pokazano tylko jedno wyrażenie używane w kontrolce QueryExtender jednocześnie. Można jednak uwzględnić wiele wyrażeń wewnątrz kontrolki QueryExtender .

Wyrażenia kodu zakodowane w języku HTML

Niektóre witryny ASP.NET (szczególnie w przypadku ASP.NET MVC) w dużym stopniu korzystają ze <%= expression %> składni (często nazywanej "nuggetami kodu"), aby napisać tekst do odpowiedzi. W przypadku używania wyrażeń kodu można łatwo zapomnieć o kodowaniu HTML tekstu. Jeśli tekst pochodzi z danych wejściowych użytkownika, może pozostawić strony otwarte do ataku XSS (cross site Scripting).

ASP.NET 4 wprowadza następującą nową składnię wyrażeń kodu:

<%: expression %>

Ta składnia domyślnie używa kodowania HTML podczas zapisywania w odpowiedzi. To nowe wyrażenie skutecznie przekłada się na następujące elementy:

<%= HttpUtility.HtmlEncode(expression) %>

Na przykład <%: Request["UserInput"] %> wykonuje kodowanie HTML na wartości Request["UserInput"].

Celem tej funkcji jest możliwość zastąpienia wszystkich wystąpień starej składni nową składnią, aby nie trzeba było decydować o każdym kroku, którego należy użyć. Istnieją jednak przypadki, w których tekst będący wynikiem wyjściowym ma być html lub jest już zakodowany, w takim przypadku może to prowadzić do podwójnego kodowania.

W takich przypadkach ASP.NET 4 wprowadza nowy interfejs IHtmlString wraz z konkretną implementacją HtmlString. Wystąpienia tych typów pozwalają wskazać, że zwracana wartość jest już poprawnie zakodowana (lub w inny sposób zbadana) do wyświetlania jako HTML, dlatego wartość nie powinna być ponownie zakodowana w formacie HTML. Na przykład następujące elementy nie powinny być (i nie) kodowane w formacie HTML:

<%: new HtmlString("<strong>HTML that is not encoded</strong>") %>

ASP.NET metody pomocnika MVC 2 zostały zaktualizowane w celu pracy z tą nową składnią, aby nie były one zakodowane dwukrotnie, ale tylko wtedy, gdy jest uruchomiona ASP.NET 4. Ta nowa składnia nie działa podczas uruchamiania aplikacji przy użyciu ASP.NET 3.5 SP1.

Należy pamiętać, że nie gwarantuje to ochrony przed atakami XSS. Na przykład kod HTML używający wartości atrybutów, które nie znajdują się w cudzysłowie, może zawierać dane wejściowe użytkownika, które są nadal podatne. Należy pamiętać, że dane wyjściowe kontrolek ASP.NET i ASP.NET pomocników MVC zawsze zawierają wartości atrybutów w cudzysłowie, co jest zalecanym podejściem.

Podobnie ta składnia nie wykonuje kodowania JavaScript, na przykład podczas tworzenia ciągu Języka JavaScript na podstawie danych wejściowych użytkownika.

Zmiany szablonu projektu

We wcześniejszych wersjach ASP.NET, gdy używasz programu Visual Studio do tworzenia nowego projektu witryny sieci Web lub projektu aplikacji internetowej, wynikowe projekty zawierają tylko stronę Default.aspx, plik domyślny Web.config i App_Data folder, jak pokazano na poniższej ilustracji:

Zrzut ekranu przedstawiający menu pliku programu Visual Studio. Wyróżniono przykładowy nowy projekt z domyślnym plikiem i folderem.

Program Visual Studio obsługuje również typ projektu Pusta witryna sieci Web, który nie zawiera żadnych plików, jak pokazano na poniższej ilustracji:

Zrzut ekranu przedstawiający menu pliku programu Visual Studio. Przykładowy katalog projektu jest wyświetlany w taki sposób, aby nie zawierał plików ani folderów.

W związku z tym dla początkujących istnieje bardzo mało wskazówek dotyczących tworzenia produkcyjnej aplikacji internetowej. W związku z tym ASP.NET 4 wprowadza trzy nowe szablony, jeden dla pustego projektu aplikacji internetowej i jeden dla projektu aplikacji internetowej i witryny sieci Web.

Pusty szablon aplikacji internetowej

Jak sugeruje nazwa, pusty szablon aplikacji internetowej jest pozbawionym projektu aplikacji internetowej. Ten szablon projektu należy wybrać w oknie dialogowym Nowy projekt programu Visual Studio, jak pokazano na poniższej ilustracji:

(Kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Podczas tworzenia pustej aplikacji internetowej ASP.NET program Visual Studio tworzy następujący układ folderu:

Zrzut ekranu przedstawiający menu pliku programu Visual Studio. Wyróżniono plik o nazwie Web dot config.

Jest to podobne do układu pustej witryny sieci Web z wcześniejszych wersji ASP.NET z jednym wyjątkiem. W programie Visual Studio 2010 puste projekty aplikacji internetowej i pustej witryny sieci Web zawierają następujący minimalny Web.config plik zawierający informacje używane przez program Visual Studio do identyfikowania struktury docelowej projektu:

! <?wersja xml =

Bez tej właściwości targetFramework program Visual Studio domyślnie określa wartość docelową .NET Framework 2.0, aby zachować zgodność podczas otwierania starszych aplikacji.

Szablony projektów aplikacji internetowych i witryn sieci Web

Pozostałe dwa nowe szablony projektów dostarczane z programem Visual Studio 2010 zawierają istotne zmiany. Na poniższej ilustracji przedstawiono układ projektu utworzony podczas tworzenia nowego projektu aplikacji internetowej. (Układ projektu witryny sieci Web jest praktycznie identyczny).

Projekt zawiera wiele plików, które nie zostały utworzone we wcześniejszych wersjach. Ponadto nowy projekt aplikacji internetowej jest skonfigurowany z podstawową funkcjonalnością członkostwa, która umożliwia szybkie rozpoczęcie zabezpieczania dostępu do nowej aplikacji. W związku z tym dołączeniem Web.config plik nowego projektu zawiera wpisy używane do konfigurowania członkostwa, ról i profilów. Poniższy przykład przedstawia Web.config plik dla nowego projektu aplikacji internetowej. (W tym przypadku funkcja roleManager jest wyłączona).

(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Projekt zawiera również drugi Web.config plik w Account katalogu. Drugi plik konfiguracji zapewnia sposób zabezpieczania dostępu do strony ChangePassword.aspx dla zalogowanych użytkowników. Poniższy przykład przedstawia zawartość drugiego Web.config pliku.

<?xml version=

Strony utworzone domyślnie w nowych szablonach projektów również zawierają więcej zawartości niż w poprzednich wersjach. Projekt zawiera domyślną stronę wzorcową i plik CSS, a domyślna strona (Default.aspx) jest domyślnie skonfigurowana do używania strony wzorcowej. Wynikiem jest to, że po pierwszym uruchomieniu aplikacji internetowej lub witryny sieci Web domyślna (strona główna) jest już funkcjonalna. W rzeczywistości jest ona podobna do domyślnej strony widocznej podczas uruchamiania nowej aplikacji MVC.

(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Celem tych zmian w szablonach projektu jest przedstawienie wskazówek dotyczących sposobu tworzenia nowej aplikacji internetowej. W przypadku semantycznie poprawnego, ścisłego znaczników zgodnego z językiem XHTML 1.0 i układu określonego przy użyciu css strony w szablonach reprezentują najlepsze rozwiązania dotyczące tworzenia aplikacji internetowych ASP.NET 4. Strony domyślne mają również układ dwukolumny, który można łatwo dostosować.

Załóżmy na przykład, że w przypadku nowej aplikacji internetowej chcesz zmienić niektóre kolory i wstawić logo firmy zamiast logo Moja aplikacja ASP.NET. W tym celu utworzysz nowy katalog w obszarze Content do przechowywania obrazu logo:

Zrzut ekranu przedstawiający katalog plików z folderem images zawierającym plik logo.

Aby dodać obraz do strony, otwórz Site.Master plik, znajdź, gdzie zdefiniowano tekst My ASP.NET Application i zastąp go elementem obrazu , którego atrybut src został ustawiony na nowy obraz logo, jak w poniższym przykładzie:

(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Następnie możesz przejść do pliku Site.css i zmodyfikować definicje klas CSS, aby zmienić kolor tła strony, a także nagłówek.

Wynikiem tych zmian jest to, że można wyświetlić dostosowaną stronę główną z bardzo małym nakładem pracy:

(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Ulepszenia CSS

Jednym z głównych obszarów pracy w ASP.NET 4 było ułatwienie renderowania kodu HTML zgodnego z najnowszymi standardami HTML. Obejmuje to zmiany sposobu, w jaki ASP.NET kontrolki serwera sieci Web używają stylów CSS.

Ustawienie zgodności dla renderowania

Domyślnie, gdy aplikacja internetowa lub witryna sieci Web jest przeznaczona dla .NET Framework 4, atrybut controlRenderingCompatibilityVersion elementu pages jest ustawiony na "4.0". Ten element jest zdefiniowany w pliku na poziomie Web.config maszyny i domyślnie dotyczy wszystkich aplikacji ASP.NET 4:

<system.web> 
  <pages controlRenderingCompatibilityVersion="3.5|4.0"/> 
</system.web>

Wartość controlRenderingCompatibility jest ciągiem, który umożliwia potencjalne nowe definicje wersji w przyszłych wersjach. W bieżącej wersji obsługiwane są następujące wartości dla tej właściwości:

"3.5". To ustawienie wskazuje starsze renderowanie i znaczniki. Znaczniki renderowane przez kontrolki są zgodne w 100% z poprzednimi wersjami, a ustawienie właściwości xhtmlConformance jest uznawane.
"4.0". Jeśli właściwość ma to ustawienie, ASP.NET kontrolki serwera sieci Web wykonaj następujące czynności:
Właściwość xhtmlConformance jest zawsze traktowana jako "Strict". W rezultacie kontrolki renderuje znaczniki XHTML 1.0 Strict.
Wyłączenie kontrolek innych niż wejściowe nie powoduje już renderowania nieprawidłowych stylów.
Elementy div wokół ukrytych pól są teraz stylowane, więc nie zakłócają reguł CSS utworzonych przez użytkownika.
Kontrolki menu renderuje znaczniki, które są semantycznie poprawne i zgodne z wytycznymi dotyczącymi ułatwień dostępu.
Kontrolki weryfikacji nie renderują stylów wbudowanych.
Kontrolki, które wcześniej renderowane obramowanie="0" (kontrolki pochodzące z kontrolki ASP.NET Tabela i kontrolka ASP.NET Obraz ) nie będą już renderować tego atrybutu.

Wyłączanie kontrolek

W ASP.NET 3.5 z dodatkiem SP1 i wcześniejszymi wersjami platforma renderuje atrybut wyłączony w adiustacji HTML dla dowolnej kontrolki, której właściwość Enabled ma wartość false. Jednak zgodnie ze specyfikacją HTML 4.01 tylko elementy wejściowe powinny mieć ten atrybut.

W ASP.NET 4 można ustawić właściwość controlRenderingCompatibilityVersion na "3.5", jak w poniższym przykładzie:

<system.web> 
  <pages controlRenderingCompatibilityVersion="3.5"/> 
</system.web>

Możesz utworzyć znaczniki dla kontrolki Etykieta , tak jak poniżej, co powoduje wyłączenie kontrolki:

<asp:Label id="Label" runat="server" Text="Test" Enabled="false">

Kontrolka Etykieta renderuje następujący kod HTML:

<span id="Label1" disabled="disabled">Test</span>

W ASP.NET 4 można ustawić kontrolkęRenderingCompatibilityVersion na "4.0". W takim przypadku tylko kontrolki renderujące elementy wejściowe będą renderować atrybut wyłączony , gdy właściwość Enabled kontrolki ma wartość false. Kontrolki, które nie renderują elementów wejściowych HTML, zamiast tego renderują atrybut klasy odwołujący się do klasy CSS, której można użyć do zdefiniowania wyłączonego wyszukiwania kontrolki. Na przykład kontrolka Etykieta wyświetlana we wcześniejszym przykładzie spowoduje wygenerowanie następujących znaczników:

<span id="Span1" class="aspnetdisabled">Test</span>

Domyślną wartością klasy określonej dla tej kontrolki jest "aspNetDisabled". Tę wartość domyślną można jednak zmienić, ustawiając statyczną właściwość DisabledCssClass klasy WebControl . W przypadku deweloperów kontrolek zachowanie używane dla określonej kontrolki można również zdefiniować przy użyciu właściwości SupportsDisabledAttribute .

Ukrywanie elementów div wokół ukrytych pól

ASP.NET 2.0 i nowszych wersjach renderuje ukryte pola specyficzne dla systemu (takie jak ukryty element używany do przechowywania informacji o stanie widoku) wewnątrz elementu div w celu zachowania zgodności ze standardem XHTML. Może to jednak spowodować problem, gdy reguła CSS wpływa na elementy div na stronie. Na przykład może to spowodować wyświetlenie wiersza o jednym pikselu na stronie wokół ukrytych elementów div . W ASP.NET 4 elementy div , które ujęły ukryte pola generowane przez ASP.NET dodać odwołanie do klasy CSS, jak pokazano w poniższym przykładzie:

<div class="aspNetHidden">...</div>

Następnie można zdefiniować klasę CSS, która ma zastosowanie tylko do ukrytych elementów generowanych przez ASP.NET, jak w poniższym przykładzie:

<style type="text/css"> 
  DIV# aspNetHidden {border:0;} 

</style>

Renderowanie tabeli zewnętrznej dla kontrolek szablonowych

Domyślnie następujące ASP.NET kontrolki serwera sieci Web obsługujące szablony są automatycznie opakowane w tabelę zewnętrzną, która jest używana do stosowania stylów wbudowanych:

Formview
Zaloguj się
Passwordrecovery
Changepassword
Kreatora
Createuserwizard

Do tych kontrolek dodano nową właściwość o nazwie RenderOuterTable , która umożliwia usunięcie tabeli zewnętrznej z znaczników. Rozważmy na przykład następujący przykład kontrolki FormView :

<asp:FormView ID="FormView1" runat="server"> 
  <ItemTemplate> 
      Content 
  </ItemTemplate> 

</asp:FormView>

Ten znacznik renderuje następujące dane wyjściowe na stronie, która zawiera tabelę HTML:

<table cellspacing="0" border="0" id="Table1" style="border-collapse:collapse;"> 
  <tr> 
    <td colspan="2"> 
      Content 
    </td> 
  </tr> 

</table>

Aby zapobiec renderowaniu tabeli, możesz ustawić właściwość RenderOuterTable kontrolki FormView, jak w poniższym przykładzie:

<asp:FormView ID="FormView1" runat="server" RenderOuterTable="false">

W poprzednim przykładzie są renderowane następujące dane wyjściowe bez elementów tabeli, tr i td :

Zawartość

To ulepszenie może ułatwić styl zawartości kontrolki za pomocą arkuszy CSS, ponieważ kontrolka nie renderuje nieoczekiwanych tagów.

Uwaga

Uwaga Ta zmiana wyłącza obsługę funkcji automatycznego formatowania w projektancie programu Visual Studio 2010, ponieważ nie ma już elementu tabeli , który może hostować atrybuty stylu generowane przez opcję automatycznego formatowania.

Ulepszenia kontrolki ListView

Kontrolka ListView została łatwiejsza w użyciu w ASP.NET 4. Wcześniejsza wersja kontrolki wymaganej do określenia szablonu układu zawierającego kontrolkę serwera o znanym identyfikatorze. Poniższy kod przedstawia typowy przykład użycia kontrolki ListView w ASP.NET 3.5.

<asp:ListView ID="ListView1" runat="server"> 
  <LayoutTemplate> 
    <asp:PlaceHolder ID="ItemPlaceHolder" runat="server"></asp:PlaceHolder> 
  </LayoutTemplate> 
  <ItemTemplate> 
    <% Eval("LastName")%> 
  </ItemTemplate> 
</asp:ListView>

W ASP.NET 4 kontrolka ListView nie wymaga szablonu układu. Znaczniki pokazane w poprzednim przykładzie można zastąpić następującymi znacznikami:

<asp:ListView ID="ListView1" runat="server"> 
  <ItemTemplate> 
    <% Eval("LastName")%> 
  </ItemTemplate> 

</asp:ListView>

Ulepszenia kontrolek CheckBoxList i RadioButtonList

W ASP.NET 3.5 można określić układ checkBoxList i RadioButtonList przy użyciu następujących dwóch ustawień:

Przepływ. Kontrolka renderuje zakres elementów, aby zawierały jego zawartość.
Tabela. Kontrolka renderuje element tabeli , aby zawierał jego zawartość.

W poniższym przykładzie pokazano znaczniki dla każdej z tych kontrolek.

<asp:CheckBoxList ID="CheckBoxList1" runat="server" RepeatLayout="Flow"> 
  <asp:ListItem Text="CheckBoxList" Value="cbl" /> 
</asp:CheckBoxList> 

<asp:RadioButtonList runat="server" RepeatLayout="Table"> 
  <asp:ListItem Text="RadioButtonList" Value="rbl" /> 
</asp:RadioButtonList>

Domyślnie kontrolki renderować kod HTML podobny do następującego:

<span id="Span2"><input id="CheckBoxList1_0" type="checkbox" 
    name="CheckBoxList1$0" /><label for="CheckBoxList1_0">CheckBoxList</label></span> 
    
<table id="RadioButtonList1" border="0"> 
  <tr> 
    <td><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></td> 
  </tr> 

</table>

Ponieważ te kontrolki zawierają listy elementów, aby renderować semantycznie poprawny kod HTML, powinny renderować zawartość przy użyciu elementów listy HTML (li). Ułatwia to użytkownikom odczytywanie stron internetowych przy użyciu technologii pomocniczej i ułatwia styl kontrolek przy użyciu arkuszy CSS.

W ASP.NET 4 kontrolki CheckBoxList i RadioButtonList obsługują następujące nowe wartości właściwości RepeatLayout :

OrderedList — zawartość jest renderowana jako elementy li w elemecie ol .
UnorderedList — zawartość jest renderowana jako elementy li w elemecie ul .

W poniższym przykładzie pokazano, jak używać tych nowych wartości.

<asp:CheckBoxList ID="CheckBoxList1" runat="server" 
      RepeatLayout="OrderedList">
  <asp:ListItem Text="CheckBoxList" Value="cbl" />
</asp:CheckBoxList>

<asp:RadioButtonList ID="RadioButtonList1" runat="server"  
      RepeatLayout="UnorderedList">
  <asp:ListItem Text="RadioButtonList" Value="rbl" />
</asp:RadioButtonList>

Powyższy kod znaczników generuje następujący kod HTML:

<ol id="CheckBoxList1">

  <li><input id="CheckBoxList1_0" type="checkbox" name="CheckBoxList1$0" value="cbl" /><label for="CheckBoxList1_0">CheckBoxList</label></li>
</ol>
    
<ul id="RadioButtonList1">
  <li><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></li>

</ul>

Uwaga

Uwaga Jeśli ustawisz właściwość RepeatLayout na OrderedList lub UnorderedList, właściwość RepeatDirection nie może być już używana i zgłosi wyjątek w czasie wykonywania, jeśli właściwość została ustawiona w adiustacji lub kodzie. Właściwość nie ma wartości, ponieważ układ wizualny tych kontrolek jest definiowany przy użyciu arkuszy CSS.

Przed ASP.NET 4 kontrolka Menu renderowała serię tabel HTML. Utrudniło to stosowanie stylów CSS poza ustawieniem właściwości wbudowanych, a także nie było zgodne ze standardami ułatwień dostępu.

W ASP.NET 4 kontrolka renderuje teraz kod HTML przy użyciu semantycznego znaczników, który składa się z nieurządkowanej listy i elementów listy. Poniższy przykład przedstawia znaczniki na stronie ASP.NET dla kontrolki Menu .

<asp:Menu ID="Menu1" runat="server"> 
  <Items> <asp:MenuItem Text="Home" Value="Home" /> 
    <asp:MenuItem Text="About" Value="About" /> 
  </Items> 

</asp:Menu>

Gdy strona jest renderowana, kontrolka generuje następujący kod HTML (kod onclick został pominięty w celu zapewnienia przejrzystości):

<div id="Menu1"> 
  <ul> 
    <li><a href="#" onclick="...">Home</a></li> 
    <li><a href="#" onclick="...">About</a></li> 
  </ul> 

</div> 
<script type="text/javascript"> 
  new Sys.WebForms.Menu('Menu1'); 
</script>

Oprócz ulepszeń renderowania, nawigacja za pomocą klawiatury w menu została ulepszona przy użyciu zarządzania fokusem. Gdy kontrolka Menu zostanie fokus, możesz użyć klawiszy strzałek do nawigowania po elementach. Kontrolka Menu dołącza teraz również dostępne funkcje zaawansowanych aplikacji internetowych (ARIA) i atrybutycelu zwiększenia ułatwień dostępu.

Style kontrolki menu są renderowane w bloku stylów w górnej części strony, a nie zgodnie z renderowanych elementów HTML. Jeśli chcesz przejąć pełną kontrolę nad stylem kontrolki, możesz ustawić nową właściwość IncludeStyleBlock na wartość false, w tym przypadku blok stylu nie jest emitowany. Jednym ze sposobów użycia tej właściwości jest użycie funkcji automatycznego formatowania w projektancie programu Visual Studio w celu ustawienia wyglądu menu. Następnie możesz uruchomić stronę, otworzyć źródło strony, a następnie skopiować renderowany blok stylu do zewnętrznego pliku CSS. W programie Visual Studio cofnij styl i ustaw właściwość IncludeStyleBlock na wartość false. W rezultacie wygląd menu jest definiowany przy użyciu stylów w zewnętrznym arkuszu stylów.

Kreator i kontrolki CreateUserWizard

Kontrolki Kreator ASP.NET i CreateUserWizard obsługują szablony, które pozwalają zdefiniować renderowany kod HTML. (CreateUserWizard pochodzi z Kreatora). W poniższym przykładzie pokazano znaczniki dla w pełni szablonowej kontrolki CreateUserWizard :

<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="0"> 
  <HeaderTemplate> 
  </HeaderTemplate>
 
  <SideBarTemplate> 
  </SideBarTemplate>
 
  <StepNavigationTemplate> 
  </StepNavigationTemplate> 

  <StartNavigationTemplate> 
  </StartNavigationTemplate> 

  <FinishNavigationTemplate> 
  </FinishNavigationTemplate> 

  <WizardSteps> 
    <asp:CreateUserWizardStep ID="CreateUserWizardStep1" runat="server"> 
      <ContentTemplate> 
      </ContentTemplate>

      <CustomNavigationTemplate> 
      </CustomNavigationTemplate>

    </asp:CreateUserWizardStep>
 
    <asp:CompleteWizardStep ID="CompleteWizardStep1" runat="server"> 
      <ContentTemplate> 
      </ContentTemplate> 
    </asp:CompleteWizardStep> 

  </WizardSteps> 

</asp:CreateUserWizard>

Kontrolka renderuje kod HTML podobny do następującego:

<table cellspacing="0" cellpadding="0" border="0" id="CreateUserWizard1" style="border-collapse:collapse;"> 
  <tr> 
    <td>Header</td> 
  </tr> 
  <tr style="height:100%;"> 
    <td> 
      <table cellspacing="0" cellpadding="0" border="0" style="height:100%;width:100%;border-collapse:collapse;"> 
        <tr> 
          <td style="height:100%;width:100%;"></td> 
        </tr> 
      </table> 
    </td> 
  </tr> 
  <tr> 
    <td align="right"></td> 
  </tr> 

</table>

W ASP.NET 3.5 SP1, chociaż można zmienić zawartość szablonu, nadal masz ograniczoną kontrolę nad danymi wyjściowymi kontrolki Kreator . W ASP.NET 4 można utworzyć szablon LayoutTemplate i wstawić kontrolki Symbol zastępczy (przy użyciu nazw zarezerwowanych), aby określić sposób renderowania kontrolki Kreator . W poniższym przykładzie pokazano to:

<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="1"> 
  <LayoutTemplate> 
    <asp:PlaceHolder ID="headerPlaceholder" runat="server" /> 
    <asp:PlaceHolder ID="sideBarPlaceholder" runat="server" /> 
    <asp:PlaceHolder id="wizardStepPlaceholder" runat="server" /> 
    <asp:PlaceHolder id="navigationPlaceholder" runat="server" /> 
  </LayoutTemplate> 
  <HeaderTemplate> 
    Header 
  </HeaderTemplate> 
  <WizardSteps> 
    <asp:CreateUserWizardStep runat="server"> 
      <ContentTemplate> 
      </ContentTemplate> 
    </asp:CreateUserWizardStep> 
    <asp:CompleteWizardStep runat="server"> 
      <ContentTemplate> 
      </ContentTemplate> 
    </asp:CreateUserWizardStep> 
  </WizardSteps> 

</asp:CreateUserWizard>

Przykład zawiera następujące nazwane symbole zastępcze w elemecie LayoutTemplate :

headerPlaceholder — w czasie wykonywania jest to zastępowane zawartością elementu HeaderTemplate .
sideBarPlaceholder — w czasie wykonywania jest to zastępowane zawartością elementu SideBarTemplate .
wizardStepPlaceHolder — w czasie wykonywania jest on zastępowany zawartością elementu WizardStepTemplate .
navigationPlaceholder — w czasie wykonywania jest to zastępowane przez zdefiniowane szablony nawigacji.

Znaczniki w przykładzie używającym symboli zastępczych renderuje następujący kod HTML (bez zawartości faktycznie zdefiniowanej w szablonach):

<span>
</span>

Jedynym kodem HTML, który nie jest teraz zdefiniowany przez użytkownika, jest element span . (Przewidujemy, że w przyszłych wersjach nawet element span nie zostanie renderowany). Teraz zapewnia pełną kontrolę nad praktycznie całą zawartością, która jest generowana przez kontrolkę Kreator .

ASP.NET MVC

ASP.NET MVC została wprowadzona jako struktura dodatku do ASP.NET 3.5 SP1 w marcu 2009 r. Program Visual Studio 2010 zawiera ASP.NET MVC 2, który zawiera nowe funkcje i możliwości.

Obsługa obszarów

Obszary umożliwiają grupowanie kontrolerów i widoków w sekcjach dużej aplikacji w względnej izolacji od innych sekcji. Każdy obszar można zaimplementować jako oddzielny projekt MVC ASP.NET, do którego można się następnie odwoływać przez główną aplikację. Ułatwia to zarządzanie złożonością podczas tworzenia dużej aplikacji i ułatwia wielu zespołom współpracę nad pojedynczą aplikacją.

Obsługa walidacji atrybutów Data-Annotation

Atrybuty DataAnnotations umożliwiają dołączanie logiki walidacji do modelu przy użyciu atrybutów metadanych. Atrybuty DataAnnotations zostały wprowadzone w ASP.NET danych dynamicznych w ASP.NET 3.5 SP1. Te atrybuty zostały zintegrowane z domyślnym binderem modelu i zapewniają oparte na metadanych środki do weryfikowania danych wejściowych użytkownika.

Pomocnicy z szablonami

Pomocnicy szablonów umożliwiają automatyczne kojarzenie szablonów edycji i wyświetlania z typami danych. Na przykład można użyć pomocnika szablonu, aby określić, że element interfejsu użytkownika selektora dat jest automatycznie renderowany dla wartości System.DateTime . Jest to podobne do szablonów pól w ASP.NET danych dynamicznych.

Metody pomocnika Html.EditorFor i Html.DisplayFor mają wbudowaną obsługę renderowania standardowych typów danych, a także złożonych obiektów z wieloma właściwościami. Dostosowują również renderowanie, umożliwiając stosowanie atrybutów adnotacji danych, takich jak DisplayName i ScaffoldColumn , do obiektu ViewModel .

Często chcesz jeszcze bardziej dostosować dane wyjściowe z pomocników interfejsu użytkownika i mieć pełną kontrolę nad tym, co jest generowane. Metody pomocnicze Html.EditorFor i Html.DisplayFor obsługują tę funkcję przy użyciu mechanizmu tworzenia szablonów, który umożliwia definiowanie szablonów zewnętrznych, które mogą zastępować i kontrolować renderowane dane wyjściowe. Szablony można renderować indywidualnie dla klasy.

Dane dynamiczne

Dane dynamiczne zostały wprowadzone w wersji .NET Framework 3.5 SP1 w połowie 2008 roku. Ta funkcja oferuje wiele ulepszeń tworzenia aplikacji opartych na danych, w tym następujące:

Środowisko RAD do szybkiego tworzenia witryny internetowej opartej na danych.
Automatyczna walidacja oparta na ograniczeniach zdefiniowanych w modelu danych.
Możliwość łatwego zmieniania znaczników generowanych dla pól w kontrolkach GridView i DetailsView przy użyciu szablonów pól, które są częścią projektu danych dynamicznych.

Uwaga

Uwaga Aby uzyskać więcej informacji, zobacz dokumentację dotyczącą danych dynamicznych w bibliotece MSDN.

W przypadku ASP.NET 4 dane dynamiczne zostały ulepszone, aby zapewnić deweloperom jeszcze więcej możliwości szybkiego tworzenia witryn internetowych opartych na danych.

Włączanie danych dynamicznych dla istniejących projektów

Funkcje danych dynamicznych dostarczane w .NET Framework 3.5 SP1 przyniosły nowe funkcje, takie jak:

Szablony pól — zapewniają szablony oparte na typach danych dla kontrolek powiązanych z danymi. Szablony pól zapewniają prostszy sposób dostosowywania wyglądu kontrolek danych niż używanie pól szablonu dla każdego pola.
Walidacja — dane dynamiczne umożliwiają używanie atrybutów w klasach danych do określania poprawności typowych scenariuszy, takich jak wymagane pola, sprawdzanie zakresu, sprawdzanie typów, dopasowywanie wzorców przy użyciu wyrażeń regularnych i walidacja niestandardowa. Walidacja jest wymuszana przez kontrolki danych.

Jednak te funkcje miały następujące wymagania:

Warstwa dostępu do danych musiała być oparta na programie Entity Framework lub LINQ to SQL.
Jedynymi kontrolkami źródła danych obsługiwanymi dla tych funkcji były kontrolki EntityDataSource lub LinqDataSource .
Funkcje wymagały projektu sieci Web, który został utworzony przy użyciu szablonów dynamicznych danych lub jednostek danych dynamicznych, aby mieć wszystkie pliki wymagane do obsługi tej funkcji.

Głównym celem obsługi danych dynamicznych w ASP.NET 4 jest włączenie nowej funkcji danych dynamicznych dla dowolnej aplikacji ASP.NET. W poniższym przykładzie przedstawiono znaczniki dla kontrolek, które mogą korzystać z funkcji danych dynamicznych na istniejącej stronie.

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="True" 
    DataKeyNames="ProductID" DataSourceID="LinqDataSource1"> 
</asp:GridView> 
<asp:LinqDataSource ID="LinqDataSource1" runat="server" 
    ContextTypeName="DataClassesDataContext" EnableDelete="True" EnableInsert="True" 
    EnableUpdate="True" TableName="Products"> 

</asp:LinqDataSource>

W kodzie strony należy dodać następujący kod, aby umożliwić obsługę danych dynamicznych dla tych kontrolek:

GridView1.EnableDynamicData(typeof(Product));

Gdy kontrolka GridView jest w trybie edycji, dane dynamiczne automatycznie weryfikują, czy wprowadzone dane są w odpowiednim formacie. Jeśli tak nie jest, zostanie wyświetlony komunikat o błędzie.

Ta funkcja zapewnia również inne korzyści, takie jak możliwość określania wartości domyślnych dla trybu wstawiania. Bez danych dynamicznych, aby zaimplementować wartość domyślną dla pola, musisz dołączyć do zdarzenia, zlokalizować kontrolkę (przy użyciu kontrolki FindControl) i ustawić jej wartość. W ASP.NET 4 wywołanie EnableDynamicData obsługuje drugi parametr, który umożliwia przekazanie wartości domyślnych dla dowolnego pola w obiekcie, jak pokazano w tym przykładzie:

DetailsView1.EnableDynamicData(typeof(Product), new { ProductName = "DefaultName" });

Deklaratywna składnia kontrolki DynamicDataManager

Kontrolka DynamicDataManager została ulepszona, aby można było ją deklaratywnie skonfigurować, podobnie jak w przypadku większości kontrolek w ASP.NET, zamiast tylko w kodzie. Znaczniki kontrolki DynamicDataManager wyglądają podobnie do następującego przykładu:

<asp:DynamicDataManager ID="DynamicDataManager1" runat="server" 
    AutoLoadForeignKeys="true"> 
  <DataControls> 
    <asp:DataControlReference ControlID="GridView1" /> 
  </DataControls> 

</asp:DynamicDataManager> 
<asp:GridView id="GridView1" runat="server" 
</asp:GridView>

Ta adiustacja umożliwia zachowanie danych dynamicznych dla kontrolki GridView1, do którego odwołuje się kontrolka DataControls kontrolki DynamicDataManager .

Szablony jednostek

Szablony jednostek oferują nowy sposób dostosowywania układu danych bez konieczności tworzenia strony niestandardowej. Szablony stron używają kontrolki FormView (zamiast kontrolki DetailsView , używanej w szablonach stron we wcześniejszych wersjach danych dynamicznych) i kontrolki DynamicEntity do renderowania szablonów jednostek. Zapewnia to większą kontrolę nad znacznikami renderowanych przez dane dynamiczne.

Na poniższej liście przedstawiono nowy układ katalogu projektu zawierający szablony jednostek:

\DynamicData\EntityTemplates
\DynamicData\EntityTemplates\Default.ascx
\DynamicData\EntityTemplates\Default_Edit.ascx
\DynamicData\EntityTemplates\Default_Insert.ascx

Katalog EntityTemplate zawiera szablony dotyczące wyświetlania obiektów modelu danych. Domyślnie obiekty są renderowane przy użyciu szablonu Default.ascx , który udostępnia znaczniki, które wyglądają podobnie jak znaczniki utworzone przez kontrolkę DetailsView używanej przez dane dynamiczne w ASP.NET 3.5 SP1. W poniższym przykładzie przedstawiono znaczniki dla kontrolki Default.ascx :

<asp:EntityTemplate runat="server" ID="TemplateContainer1"> 
  <ItemTemplate> 
    <tr 
      <td> 
        <asp:Label ID="Label1" runat="server" OnInit="Label_Init" /> 
      </td> 
      <td> 
        <asp:DynamicControl runat="server" OnInit="DynamicControl_Init" /> 
      </td> 
    </tr> 
  </ItemTemplate> 

</asp:EntityTemplate>

Szablony domyślne można edytować, aby zmienić wygląd i działanie całej witryny. Istnieją szablony operacji wyświetlania, edytowania i wstawiania. Nowe szablony można dodać na podstawie nazwy obiektu danych, aby zmienić wygląd i działanie tylko jednego typu obiektu. Można na przykład dodać następujący szablon:

\DynamicData\EntityTemplates\Products.aspx

Szablon może zawierać następujące znaczniki:

<tr> 
  <td>Name</td> 
  <td><asp:DynamicControl runat="server" DataField="ProductName" /></td> 
  <td>Category</td> 
  <td><asp:DynamicControl runat="server" DataField="Category" /></td> 

</tr>

Nowe szablony jednostek są wyświetlane na stronie przy użyciu nowej kontrolki DynamicEntity . W czasie wykonywania ta kontrolka jest zastępowana zawartością szablonu jednostki. Poniższy znacznik przedstawia kontrolkę FormView w szablonie Detail.aspx strony, która używa szablonu jednostki. Zwróć uwagę na element DynamicEntity w znaczniku.

<asp:FormView runat="server" ID="FormView1" 
    DataSourceID="DetailsDataSource" 
    OnItemDeleted="FormView1_ItemDeleted"> 
  <ItemTemplate> 
    <table class="DDDetailsTable" cellpadding="6"> 
      <asp:DynamicEntity runat="server" /> 
      <tr class="td"> 
        <td colspan="2"> 
          <asp:DynamicHyperLink ID="EditHyperLink" runat="server" 
              Action="Edit" Text="Edit" /> 
          <asp:LinkButton ID="DeleteLinkButton" runat="server" 
              CommandName="Delete" 
              CausesValidation="false" 
              OnClientClick='return confirm("Are you sure you want to delete this item?");' 
              Text="Delete" /> 
        </td> 
      </tr> 
    </table> 
  </ItemTemplate> 

</asp:FormView>

Nowe szablony pól dla adresów URL i adresów Email

ASP.NET 4 wprowadzono dwa nowe wbudowane szablony EmailAddress.ascx pól i Url.ascx. Te szablony są używane dla pól oznaczonych jako EmailAddress lub Url z atrybutem DataType . W przypadku obiektów EmailAddress pole jest wyświetlane jako hiperlink utworzony przy użyciu protokołu mailto: . Gdy użytkownik kliknie link, otworzy klienta poczty e-mail użytkownika i utworzy szkielet wiadomości. Obiekty wpisane jako Adres URL są wyświetlane jako zwykłe hiperlinki.

W poniższym przykładzie przedstawiono sposób oznaczania pól.

[DataType(DataType.EmailAddress)] 
public object HomeEmail { get; set; } 

[DataType(DataType.Url)] 
public object Website { get; set; }

Tworzenie linków za pomocą kontrolki DynamicHyperLink

Dane dynamiczne używają nowej funkcji routingu, która została dodana w .NET Framework 3.5 SP1, aby kontrolować adresy URL widoczne dla użytkowników końcowych podczas uzyskiwania dostępu do witryny sieci Web. Nowa kontrolka DynamicHyperLink ułatwia tworzenie linków do stron w witrynie danych dynamicznych. W poniższym przykładzie pokazano, jak używać kontrolki DynamicHyperLink :

<asp:DynamicHyperLink ID="ListHyperLink" runat="server" 
    Action="List" TableName="Products"> 
    Show all products 
</asp:DynamicHyperLink>

Ten znacznik tworzy link wskazujący stronę Lista dla Products tabeli na podstawie tras zdefiniowanych w Global.asax pliku. Kontrolka automatycznie używa domyślnej nazwy tabeli opartej na stronie Dane dynamiczne.

Obsługa dziedziczenia w modelu danych

Zarówno platforma Entity Framework, jak i LINQ to SQL obsługują dziedziczenie w swoich modelach danych. Przykładem może być baza danych zawierająca tabelę InsurancePolicy . Może również zawierać CarPolicy tabele z HousePolicy tymi samymi polami, które mają te same pola, InsurancePolicy a następnie dodawać więcej pól. Dane dynamiczne zostały zmodyfikowane, aby zrozumieć dziedziczone obiekty w modelu danych i obsługiwać tworzenie szkieletów dla dziedzicowanych tabel.

Obsługa relacji wiele-do-wielu (tylko platforma Entity Framework)

Struktura Entity Framework ma rozbudowaną obsługę relacji wiele-do-wielu między tabelami, które są implementowane przez uwidacznianie relacji jako kolekcji w obiekcie jednostki . Dodano szablony nowych ManyToMany.ascx i ManyToMany_Edit.ascx pól w celu zapewnienia obsługi wyświetlania i edytowania danych, które są zaangażowane w relacje wiele-do-wielu.

Nowe atrybuty do wyświetlania kontrolek i obsługi wyliczenia

Dodano element DisplayAttribute , aby zapewnić dodatkową kontrolę nad sposobem wyświetlania pól. Atrybut DisplayName we wcześniejszych wersjach danych dynamicznych umożliwia zmianę nazwy używanej jako podpis dla pola. Nowa klasa DisplayAttribute umożliwia określenie większej liczby opcji wyświetlania pola, na przykład kolejności wyświetlania pola i tego, czy pole będzie używane jako filtr. Atrybut zapewnia również niezależną kontrolę nad nazwą używaną dla etykiet w kontrolce GridView , nazwą używaną w kontrolce DetailsView , tekstem pomocy dla pola i znakiem wodnym używanym dla pola (jeśli pole akceptuje wprowadzanie tekstu).

Dodano klasę EnumDataTypeAttribute , aby umożliwić mapowanie pól na wyliczenia. Po zastosowaniu tego atrybutu do pola należy określić typ wyliczenia. Dane dynamiczne używają nowego Enumeration.ascx szablonu pola do tworzenia interfejsu użytkownika do wyświetlania i edytowania wartości wyliczenia. Szablon mapuje wartości z bazy danych na nazwy w wyliczenie.

Rozszerzona obsługa filtrów

Dane dynamiczne 1.0 dostarczane z wbudowanymi filtrami dla kolumn logicznych i kolumn klucza obcego. Filtry nie zezwalały na określenie, czy były wyświetlane, czy w jakiej kolejności były wyświetlane. Nowy atrybut DisplayAttribute rozwiązuje oba te problemy, dając kontrolę nad tym, czy kolumna jest wyświetlana jako filtr i w jakiej kolejności będzie wyświetlana.

Dodatkowe ulepszenie polega na tym, że obsługa filtrowania została ponownie napisanaaby korzystać z nowej funkcji Web Forms. Dzięki temu można tworzyć filtry bez konieczności znajomości kontroli źródła danych, z którą będą używane filtry. Wraz z tymi rozszerzeniami filtry zostały również przekształcone w kontrolki szablonu, które umożliwiają dodawanie nowych. Na koniec wymieniona wcześniej klasa DisplayAttribute zezwala na zastąpienie domyślnego filtru w taki sam sposób, w jaki interfejs użytkownika Umożliwia zastąpienie domyślnego szablonu pola dla kolumny.

Ulepszenia tworzenia aplikacji internetowych w programie Visual Studio 2010

Tworzenie aplikacji internetowych w programie Visual Studio 2010 zostało ulepszone w celu zwiększenia zgodności css, zwiększenia produktywności dzięki kodom HTML i ASP.NET fragmentów znaczników oraz nowym dynamicznym kodom JavaScript funkcji IntelliSense.

Ulepszona zgodność z arkuszami CSS

Projektant deweloperów programu Visual Web w programie Visual Studio 2010 został zaktualizowany w celu poprawy zgodności standardów CSS 2.1. Projektant lepiej zachowuje integralność źródła HTML i jest bardziej niezawodny niż w poprzednich wersjach programu Visual Studio. Wprowadzono również ulepszenia architektury, które umożliwią przyszłe ulepszenia renderowania, układu i możliwości obsługi.

Fragmenty kodu HTML i JavaScript

W edytorze HTML funkcja IntelliSense automatycznie wypełnia nazwy tagów. Funkcja fragmentów kodu IntelliSense automatycznie wypełnia całe tagi i nie tylko. W programie Visual Studio 2010 fragmenty kodu IntelliSense są obsługiwane w języku JavaScript, a także w języku C# i Visual Basic, które były obsługiwane we wcześniejszych wersjach programu Visual Studio.

Program Visual Studio 2010 zawiera ponad 200 fragmentów kodu, które ułatwiają automatyczne uzupełnianie typowych tagów ASP.NET i HTML, w tym wymaganych atrybutów (takich jak runat="serwer") i typowe atrybuty specyficzne dla tagu (na przykład id, DataSourceID, ControlToValidate i Text).

Możesz pobrać dodatkowe fragmenty kodu lub napisać własne fragmenty kodu, które hermetyzują bloki znaczników używanych przez Ciebie lub twój zespół do typowych zadań.

Ulepszenia funkcji IntelliSense w języku JavaScript

W programie Visual 2010 funkcja IntelliSense języka JavaScript została przeprojektowana, aby zapewnić jeszcze bogatsze środowisko edycji. Funkcja IntelliSense rozpoznaje teraz obiekty, które zostały dynamicznie generowane przez metody, takie jak registerNamespace i podobne techniki używane przez inne struktury Języka JavaScript. Ulepszono wydajność w celu analizowania dużych bibliotek skryptu i wyświetlania funkcji IntelliSense z niewielkim opóźnieniem przetwarzania. Zgodność została znacznie zwiększona, aby obsługiwać prawie wszystkie biblioteki innych firm i obsługiwać zróżnicowane style kodowania. Komentarze dokumentacji są teraz analizowane podczas wpisywania i są natychmiast używane przez funkcję IntelliSense.

Wdrażanie aplikacji internetowej za pomocą programu Visual Studio 2010

Gdy ASP.NET deweloperzy wdrażają aplikację internetową, często stwierdzają, że napotykają problemy, takie jak:

Wdrażanie w udostępnionej witrynie hostingu wymaga takich technologii jak FTP, które mogą być powolne. Ponadto należy ręcznie wykonywać zadania, takie jak uruchamianie skryptów SQL w celu skonfigurowania bazy danych i należy zmienić ustawienia usług IIS, takie jak konfigurowanie folderu katalogu wirtualnego jako aplikacji.
Oprócz wdrażania plików aplikacji sieci Web w środowisku przedsiębiorstwa administratorzy muszą często modyfikować ASP.NET plików konfiguracji i ustawień usług IIS. Administratorzy bazy danych muszą uruchamiać serię skryptów SQL, aby uzyskać uruchomioną bazę danych aplikacji. Takie instalacje intensywnie pracują, często trwają kilka godzin i muszą być starannie udokumentowane.

Program Visual Studio 2010 zawiera technologie, które umożliwiają bezproblemowe wdrażanie aplikacji internetowych. Jedną z tych technologii jest narzędzie wdrażania sieci Web usług IIS (MsDeploy.exe).

Funkcje wdrażania sieci Web w programie Visual Studio 2010 obejmują następujące główne obszary:

Tworzenie pakietów internetowych
Web.config przekształcenia
Wdrażanie bazy danych
Publikowanie jednym kliknięciem dla aplikacji internetowych

Poniższe sekcje zawierają szczegółowe informacje o tych funkcjach.

Tworzenie pakietów internetowych

Program Visual Studio 2010 używa narzędzia MSDeploy do tworzenia skompresowanego pliku (.zip) dla aplikacji, który jest nazywany pakietem sieci Web. Plik pakietu zawiera metadane dotyczące aplikacji oraz następującą zawartość:

Ustawienia usług IIS, które obejmują ustawienia puli aplikacji, ustawienia strony błędu itd.
Rzeczywista zawartość sieci Web obejmująca strony sieci Web, kontrolki użytkownika, zawartość statyczną (obrazy i pliki HTML) itd.
SQL Server schematy i dane bazy danych.
Certyfikaty zabezpieczeń, składniki do zainstalowania w usłudze GAC, ustawienia rejestru itd.

Pakiet sieci Web można skopiować do dowolnego serwera, a następnie zainstalować ręcznie przy użyciu Menedżera usług IIS. Alternatywnie w przypadku zautomatyzowanego wdrażania pakiet można zainstalować przy użyciu poleceń wiersza polecenia lub przy użyciu interfejsów API wdrażania.

Program Visual Studio 2010 udostępnia wbudowane zadania i cele programu MSBuild do tworzenia pakietów sieci Web. Aby uzyskać więcej informacji, zobacz omówienie wdrażania projektu aplikacji internetowej ASP.NET w witrynie sieci Web MSDN i 10 + 20 powodów, dla których należy utworzyć pakiet internetowy w blogu Vishal Joshi.

transformacja Web.config

W przypadku wdrażania aplikacji internetowej program Visual Studio 2010 wprowadza funkcję przekształcania dokumentów XML (XDT), która umożliwia przekształcenie Web.config pliku z ustawień programistycznych na ustawienia produkcyjne. Ustawienia przekształcania są określane w plikach przekształcania o nazwie web.debug.config, web.release.configitd. (Nazwy tych plików są zgodne z konfiguracjami programu MSBuild). Plik przekształcenia zawiera tylko zmiany, które należy wprowadzić do wdrożonego Web.config pliku. Zmiany należy określić przy użyciu prostej składni.

W poniższym przykładzie przedstawiono część web.release.config pliku, która może zostać utworzona do wdrożenia konfiguracji wydania. Słowo kluczowe Replace w przykładzie określa, że podczas wdrażania węzeł connectionString w Web.config pliku zostanie zastąpiony wartościami wymienionymi w przykładzie.

<connectionStrings xdt:Transform="Replace"> 
  <add name="BlogDB" connectionString="connection string detail]" /> 

</connectionStrings>

Aby uzyskać więcej informacji, zobacz Web.config Transformation Syntax for Web Application Project Deployment on the MSDN Web Site and Web Deployment: Web.Config Transformation on Vishal Joshi's blog (Składnia transformacjiWeb.config dla projektu aplikacji internetowej w witrynie sieci Web MSDN i wdrażaniusieci Web: Web.Config Transformation on Vishal Joshi's blog.

Wdrażanie bazy danych

Pakiet wdrażania programu Visual Studio 2010 może zawierać zależności od SQL Server baz danych. W ramach definicji pakietu należy podać parametry połączenia dla źródłowej bazy danych. Podczas tworzenia pakietu internetowego program Visual Studio 2010 tworzy skrypty SQL dla schematu bazy danych i opcjonalnie dla danych, a następnie dodaje je do pakietu. Możesz również podać niestandardowe skrypty SQL i określić sekwencję, w której powinny być uruchamiane na serwerze. W czasie wdrażania należy podać parametry połączenia, która jest odpowiednia dla serwera docelowego. Następnie proces wdrażania używa tego parametry połączenia do uruchamiania skryptów tworzących schemat bazy danych i dodawania danych.

Ponadto przy użyciu publikowania jednym kliknięciem można skonfigurować wdrożenie do publikowania bazy danych bezpośrednio po opublikowaniu aplikacji w zdalnej udostępnionej witrynie hostingu. Aby uzyskać więcej informacji, zobacz How to: Deploy a Database With a Web Application Project on the MSDN Web site and Database Deployment with VS 2010 on Vishal Joshi's blog (Wdrażanie bazy danych za pomocą projektu aplikacji internetowej MSDN i wdrażania bazy danych za pomocą programu VS 2010 w blogu Vishal Joshi).

publikowanie One-Click dla aplikacji internetowych

Program Visual Studio 2010 umożliwia również publikowanie aplikacji internetowej na serwerze zdalnym za pomocą usługi zarządzania usługami IIS. Możesz utworzyć profil publikowania dla konta hostingu lub na potrzeby testowania serwerów lub serwerów przejściowych. Każdy profil może bezpiecznie zapisywać odpowiednie poświadczenia. Następnie można wdrożyć na dowolnych serwerach docelowych jednym kliknięciem za pomocą paska narzędzi publikowania jednym kliknięciem w sieci Web. Program Visual Studio 2010 umożliwia również publikowanie przy użyciu wiersza polecenia MSBuild. Umożliwia to skonfigurowanie środowiska kompilacji zespołu w celu uwzględnienia publikowania w modelu ciągłej integracji.

Aby uzyskać więcej informacji, zobacz How to: Deploy a Web Application Project Using One-Click Publish and Web Deploy on the MSDN Web site and Web 1-Click Publish with VS 2010 on Vishal Joshi's blog (Jak wdrożyć projekt aplikacji internetowej przy użyciu programu One-Click Publish and Web Deploy w witrynie sieci Web MSDN i 1-click Publish with VS 2010 on Vishal Joshi's blog (Publikowanie za pomocą programu VS 2010). Aby wyświetlić prezentacje wideo dotyczące wdrażania aplikacji internetowej w programie Visual Studio 2010, zobacz artykuł VS 2010 for Web Developer Previews on Vishal Joshi's blog (Vs 2010 for Web Developer Previews ) w blogu Vishal Joshi.

Zasoby

Poniższe witryny sieci Web zawierają dodatkowe informacje o ASP.NET 4 i Visual Studio 2010.

ASP.NET 4 — oficjalna dokumentacja ASP.NET 4 w witrynie sieci Web MSDN.
https://www.asp.net/ — własna witryna sieci Web zespołu ASP.NET.
https://www.asp.net/dynamicdata/ i ASP.NET dynamiczną mapę zawartości danych — zasoby online w witrynie zespołu ASP.NET i w oficjalnej dokumentacji ASP.NET danych dynamicznych.
https://www.asp.net/ajax/ — główny zasób internetowy na potrzeby programowania ASP.NET Ajax.
https://devblogs.microsoft.com/dotnet/category/aspnet/ — blog zespołu deweloperów programu Visual Web zawierający informacje o funkcjach w programie Visual Studio 2010.
ASP.NET WebStack — główny zasób internetowy dla wersji zapoznawczych ASP.NET.

Disclaimer

Jest to wstępny dokument i może zostać znacząco zmieniony przed ostateczną komercyjną wersją oprogramowania opisanego w niniejszym dokumencie.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Ponieważ firma Microsoft musi reagować na zmieniające się warunki rynkowe, nie powinna być interpretowana jako zobowiązanie ze strony firmy Microsoft, a firma Microsoft nie może zagwarantować dokładności wszelkich informacji przedstawionych po dacie publikacji.

Ta biała księga jest przeznaczona tylko do celów informacyjnych. FIRMA MICROSOFT NIE UDZIELA ŻADNYCH GWARANCJI, WYRAŹNYCH, DOMNIEMANYCH ANI USTAWOWYCH, CO DO INFORMACJI W TYM DOKUMENCIE.

Przestrzeganie wszystkich obowiązujących praw autorskich jest obowiązkiem użytkownika. Bez ograniczania praw autorskich żadna część tego dokumentu nie może być odtwarzana, przechowywana w systemie pobierania lub przekazywana w jakiejkolwiek formie lub w jakikolwiek sposób (elektroniczna, mechaniczna, mechaniczna, nagrywana lub w inny sposób) lub do żadnego celu, bez wyraźnego pisemnego zezwolenia firmy Microsoft Corporation.

Firma Microsoft może mieć patenty, wnioski patentowe, znaki towarowe, prawa autorskie lub inne prawa własności intelektualnej obejmujące tematy w tym dokumencie. Z wyjątkiem wyraźnie podanych w jakiejkolwiek pisemnej umowie licencyjnej od firmy Microsoft, wyposażenie tego dokumentu nie daje żadnych licencji na te patenty, znaki towarowe, prawa autorskie lub inną własność intelektualną.

O ile nie określono inaczej, przykładowe firmy, organizacje, produkty, nazwy domen, adresy e-mail, logo, osoby, miejsca i wydarzenia przedstawione w niniejszym dokumencie są fikcyjne, a żadne skojarzenie z żadną rzeczywistą firmą, organizacją, produktem, nazwą domeny, adresem e-mail, logo, osobą, miejscem lub wydarzeniem jest zamierzone lub powinny być wnioskowane.

Firmy Microsoft i Windows są zarejestrowanymi znakami towarowymi lub znakami towarowymi firmy Microsoft Corporation w Stany Zjednoczone i/lub innych krajach.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Udostępnij za pośrednictwem

Omówienie ASP.NET 4 i Visual Studio 2010 for Web Development

Podstawowe usługi

Refaktoryzacja plików Web.config

Rozszerzone buforowanie danych wyjściowych

Automatyczne uruchamianie aplikacji internetowych

Trwałe przekierowywanie strony

Zmniejszanie stanu sesji

Rozszerzanie zakresu dozwolonych adresów URL

Rozszerzalna weryfikacja żądania

Rozszerzalność buforowania obiektów i buforowania obiektów

Rozszerzalne kodowanie kodu HTML, adresu URL i nagłówka HTTP

Monitorowanie wydajności poszczególnych aplikacji w jednym procesie roboczym

Wielowersyjność kodu

AJAX

Zestaw jQuery dołączony do Web Forms i MVC

Obsługa usługi Content Delivery Network

Skrypty jawne ScriptManager

Formularze sieci Web

Ustawianie tagów meta przy użyciu właściwości Page.MetaKeywords i Page.MetaDescription

Włączanie stanu widoku dla poszczególnych kontrolek

Zmiany możliwości przeglądarki

Korzystanie z dostawców funkcji przeglądarki

Zastępowanie funkcji ASP.NET Browser

Buforowanie obiektu HttpBrowserCapabilities

Rozszerzanie funkcji przeglądarki ASP.NET

Rozszerzanie funkcji przeglądarki przez dodanie nowych możliwości do istniejących definicji funkcji

Routing w ASP.NET 4

Routing dla stron Web Forms

Odczytywanie informacji o routingu na stronie Web Forms

Uzyskiwanie dostępu do informacji o routingu w adiustacji

Używanie danych trasy dla parametrów kontroli źródła danych

Ustawianie identyfikatorów klientów

Tworzenie przewidywalnych identyfikatorów klientów w kontrolkach Data-Bound

Utrwalanie zaznaczenia wiersza w kontrolkach danych

kontrolka wykresu ASP.NET

Dodawanie kontrolki wykresu do strony ASP.NET

Korzystanie z wykresów 3-W

Używanie podziałów skali i skali logarytmów

Filtrowanie danych za pomocą kontrolki QueryExtender

Wyszukaj

Zakres

Propertyexpression

Customexpression

Wyrażenia kodu zakodowane w języku HTML

Zmiany szablonu projektu

Pusty szablon aplikacji internetowej

Szablony projektów aplikacji internetowych i witryn sieci Web

Ulepszenia CSS

Ustawienie zgodności dla renderowania

Wyłączanie kontrolek

Ukrywanie elementów div wokół ukrytych pól

Renderowanie tabeli zewnętrznej dla kontrolek szablonowych

Ulepszenia kontrolki ListView

Ulepszenia kontrolek CheckBoxList i RadioButtonList

Ulepszenia kontrolki menu

Kreator i kontrolki CreateUserWizard

ASP.NET MVC

Obsługa obszarów

Obsługa walidacji atrybutów Data-Annotation

Pomocnicy z szablonami

Dane dynamiczne

Włączanie danych dynamicznych dla istniejących projektów

Deklaratywna składnia kontrolki DynamicDataManager

Szablony jednostek

Nowe szablony pól dla adresów URL i adresów Email

Tworzenie linków za pomocą kontrolki DynamicHyperLink

Obsługa dziedziczenia w modelu danych

Obsługa relacji wiele-do-wielu (tylko platforma Entity Framework)

Nowe atrybuty do wyświetlania kontrolek i obsługi wyliczenia

Rozszerzona obsługa filtrów

Ulepszenia tworzenia aplikacji internetowych w programie Visual Studio 2010

Ulepszona zgodność z arkuszami CSS

Fragmenty kodu HTML i JavaScript

Ulepszenia funkcji IntelliSense w języku JavaScript

Wdrażanie aplikacji internetowej za pomocą programu Visual Studio 2010

Tworzenie pakietów internetowych

transformacja Web.config

Wdrażanie bazy danych

publikowanie One-Click dla aplikacji internetowych