Übersetzung vorschlagen
 
Andere Vorschläge:

progress indicator
Keine anderen Vorschläge
MSDN Magazin > Home > Ausgaben > 2009 > MSDN Magazin August 2009 >  Daten-Leistung und Fault-Strategien in Silverli...
Inhalt anzeigen: Englisch mit deutscher ÜbersetzungInhalt anzeigen: Englisch mit deutscher Übersetzung
Dies sind maschinell übersetzte Inhalte, die von den Mitgliedern der Community bearbeitet werden können. Sie können die Übersetzung verbessern, indem Sie auf den jeweils zum Satz gehörenden Link "Bearbeiten" klicken.Mithilfe des Dropdown-Steuerelements "Inhalt anzeigen" links oben auf der Seite können Sie zudem bestimmen, ob nur der englische Originaltext, nur die deutsche Übersetzung oder beides nebeneinander angezeigt werden.
Data Points
Data Performance and Fault Strategies in Silverlight 3
John Papa
Code download available from the MSDN Code Gallery
Browse the Code Online
Silverlight applications often rely on Web services for their data. The performance of data retrieval and the ability to retrieve meaningful information about exceptions that may occur in Web services are two critical areas that have been improved in Silverlight 3.
Poor performance can be an application killer. Good strategies for retrieving data from a Web service can help, but sometimes it is necessary to retrieve an object graph that can be huge and take a long time to pass from a Web service to a client. Silverlight 3 offers a new feature that passes data from a Web service using binary encoding, and this can dramatically improve performance when passing large object graphs.
A lot can go wrong when passing data between services and Silverlight applications. That is why it is important to have a good strategy for handling exceptions that may occur when calling a Web service. Silverlight 3 offers some networking enhancements that give developers more options to pass information about managed exceptions from Web services.
In this month's column, I will demonstrate how binary encoding works, the effect it has on an application's performance, and how it behaves by demonstrating it in action. I will also walk through several techniques that can be used to pass exception information using undeclared and declared faults from Windows Communication Foundation (WCF) Web services to Silverlight. I will start by demonstrating what happens when an exception occurs and how to add some quick changes to the configuration to show information while debugging. Then, I will show you how to set up a strategic fault pattern to handle the passing exception information over SOAP services, using declared faults. All code is based on the Silverlight 3 beta and accompanies this article online.

Built for Speed
SOAP and XML passed as text severely bloats the message being passed between WCF and Silverlight. This can have a negative effect on performance, in both processing the data and the time it takes to pass the data over HTTP. Silverlight 3 introduces the ability to use a binary message encoder with WCF services that communicate with Silverlight 3 client applications. The binary message encoder can improve the performance of WCF services, especially when passing large objects graphs. The biggest gains in performance using binary message encoding are realized when passing arrays, numbers, and object graphs; lesser gains are found with very small messages and strings.
This is not a compression strategy, so there is no negative effect on performance for packing and unpacking compressed data. However, the binary encoding usually does reduce the size of the data being passed. Size reduction is not guaranteed, but is readily apparent when using large object graphs and integer data. The key improvement gained from binary encoding is that it is optimized to increase server throughput.

Configuring Binary Encoding
WCF services can communicate with Silverlight 2 applications using basicHttpBinding, which sends data as text over HTTP. When using the Silverlight-enabled WCF Service file template—which is installed when you install the Silverlight tools for Visual Studio—to create a WCF service for Silverlight 2, the binding was configured to use basicHttpBinding. This file template has been changed in Silverlight 3 to configure the WCF service to use the binary message encoder instead of text.
The Silverlight-enabled WCF Service file template configured a WCF service to use binary-encoded messaging. If you use an existing WCF service, it can be configured to use binary message encoding by creating a custom binding in the bindings section of the Web.config file. The following code sample shows the custom binding, named silverlightCustomBinding, as it appears in the <system.serviceModel> section of a configuration file. The silverlightCustomBinding, configured to use binaryMessageEncoding, is then referenced by its name in the service's endpoint configuration. 
<endpoint address="" binding="silverlightCustomBinding"
  contract="MyTestService" />
<bindings>
  <customBinding>
    <binding name="silverlightBinaryBinding">
      <binaryMessageEncoding />
      <httpTransport />
    </binding>
  </customBinding>
</bindings>
Since basicHttpBinding sends messages as text over HTTP, it is easy to debug the messages through a tool such as Fiddler. While basicHttpBinding can still be configured, the advantages of the binary encoder can be so great that it is the recommended approach. It is easy to toggle back and forth between binary and text, simply by changing the config file. This is convenient when debugging a WCF service. Binary encoding is only supported by WCF services and clients. If you need a non-WCF client application to consume your WCF service, it is best not to use binary encoding.

Binary Data Versus Text Data
The first demonstration will show the differences, in both configuration and performance, between using basicHttpBinding and a binary message encoding between WCF and Silverlight 3. The sample application included with this article breaks both examples (text and binary) out into separate services that can be called from the same Silverlight 3 client.
The configuration for these services in the Web.config file of the sample application is shown in Figure 1. The differences between the text and binary encoding configurations are in bold. Notice that the service SpeedService0 uses the basicHttpBinding, while SpeedService1 uses a customBinding with the binding configuration named silverlightBinaryBinding (shown in the previous code sample.)
 Figure 1 Configuring Text vs. Binary 
<services>
  <service 
behaviorConfiguration="SilverlightFaultData.Web.SpeedServiceBehavior" 
    name="SilverlightFaultData.Web.SpeedService0">
    <endpoint address="" binding="basicHttpBinding" 
      contract="SilverlightFaultData.Web.SpeedService0" />
    <endpoint address="mex" binding="mexHttpBinding" 
      contract="IMetadataExchange" />
  </service>
  <service
behaviorConfiguration="SilverlightFaultData.Web.SpeedServiceBehavior" 
    name="SilverlightFaultData.Web.SpeedService1">
    <endpoint address="" binding="customBinding" 
      bindingConfiguration="silverlightBinaryBinding" 
      contract="SilverlightFaultData.Web.SpeedService1" />
    <endpoint address="mex" binding="mexHttpBinding" 
      contract="IMetadataExchange" />
  </service>
</services>
The services SpeedService0 and SpeedService1 both retrieve all products and each product's category, supplier, and order details. The query (shown in Figure 2) uses the Entity Framework to retrieve the object graph.
 Figure 2 Retrieving an Object Graph 
[OperationContract]
public IList<Products> DoWork()
{
    var ctx = new NorthwindEFEntities();
    var query = from p in ctx.Products
                .Include("Categories")
                .Include("Suppliers")
                .Include("OrderDetails")
                select p;
    var productList = query.ToList<Products>();
    return productList;
}
One of the best aspects of the binary message encoding is that the only changes are found in the configuration file. No changes need be made to the code.
When the sample application is run and the Text encoding option is selected (as shown in Figure 3), the service that uses basicHttpBinding is executed. The object graph is returned and using an HTTP monitoring tool such as Fiddler or FireBug, the results show that the object graph in text form was 4MB in size and took 850ms to retrieve. When choosing the Binary encoding option, the object graph returned is 3MB and took 600ms to retrieve. While this is a small sample using a moderately sized object graph from the Northwind database, the results are in line with the Silverlight Web Service team's benchmarks . In this sample using the binary encoding, the object graph contains about 2,300 total objects and is reduced in size by 25% and is 30% faster than the text encoding.
fig03.gif
Figure 3 Getting the Data via BasicHttpBinding

Error Messages Are Data
When .NET managed exceptions are thrown in a Web service, they cannot be converted to a SOAP message and passed back to a Silverlight 2 client application. Also, Silverlight 2 cannot read SOAP faults. These two issues make debugging Web services difficult with Silverlight 2. Because SOAP Faults cannot be used with Silverlight 2, a common error message that most Silverlight 2 developers eventually run into when accessing a Web service is the infamous "The remote server returned an error: NotFound," which contains no pratical information. The original exception and its details are not transported to the Silverlight 2 client, which makes debugging the Web services difficult. Error messages contain data that is often critical in determining how the client application should respond. For example, Figure 4 shows the results of calling a Web service where an exception is thrown because the database cannot be found.
fig04.gif
Figure 4 Infamous NotFound Error
When the exception is raised, an HTTP status code of 500 is returned to Silverlight. The browser networking stack prevents Silverlight from reading responses with a status code of 500, so any SOAP fault information contained within is unavailable to the Silverlight client application. Even if the message could be retrieved, Silverlight 2 is not capable of converting the fault back into a managed exception. Both of these issues have been addressed in Silverlight 3.

Tackling the Issues
Handling exceptions with WCF and Silverlight 3 requires tackling both of these issues. First, for the exception to be returned to the Silverlight client without the networking browser stack preventing Silverlight from reading it, the status code must be changed from 500 to something that allows Silverlight to read the response. This can be achieved by deriving from the BehaviorExtensionElement and implementing IEndpointBehavior class, making it change the status code from 500 to 200 prior to whenever a fault occurs, and setting the services to use the behavior in the configuration file. The MSDN documentation contains a WCF endpoint behavior that can be used to accomplish this, and thus allow Silverlight clients access to the contents of the fault. The following code sample shows the specific code in the SilverlightFaultBehavior class that converts the status code: 
public void BeforeSendReply(ref Message reply, object correlationState)
{
    if (reply.IsFault)
    {
        HttpResponseMessageProperty property = 
          new HttpResponseMessageProperty();
        // Here the response code is changed to 200.
        property.StatusCode = System.Net.HttpStatusCode.OK;
        reply.Properties[HttpResponseMessageProperty.Name] = property;
    }
}
The SilverlightFaultBehavior class can be referenced in the Web.config file as a behavior extension, as shown in the following code snippet: 
<extensions>
  <behaviorExtensions>
    <add name="silverlightFaults"
      type="SilverlightFaultBehavior.SilverlightFaultBehavior,
        SilverlightFaultBehavior, Version=1.0.0.0,
        Culture=neutral, PublicKeyToken=null" />
  </behaviorExtensions>
</extensions>
With the SilverlightFaultBehavior in place, the second issue is getting Silverlight to be able to convert the fault to a managed exception, so it can read it. Though this is not possible with Silverlight 2, Silverlight 3 now has the ability to process faults. This allows Silverlight 3 to read a fault and present appropriate information to the user when an exception is thrown in a Web service.
The entire process of reading the exception information in Silverlight 3 goes something like this:
1) An exception is thrown in a Web service.
2) The service uses the SilverlightFaultBehavior to convert the HTTP status code from 500 to 200.
3 )The exception is converted to a SOAP fault and passed to the Silverlight 3 client.
4) The browser allows Silverlight to read the message because it has a status code of 200.
5) Code in the Silverlight 3 application checks the type of error to see if it is a FaultException or a FaultException<ExceptionDetail>.

Undeclared Faults
SOAP-based WCF services communicate errors using SOAP fault messages, or .NET managed exceptions. Therefore, the .NET managed exceptions are converted to a SOAP fault, passed to the client, and then translated back to a .NET managed exception.
Faults can be undeclared or declared, and all are strongly typed. Undeclared faults are not specified in the operation contract and should only be used for debugging. Undeclared faults return the exception message to the client exactly as it was raised in the Web service. To allow an undeclared fault, the config element's includeExceptionDetailInFaults attribute must be set to true, as shown below: 
<serviceDebug> 
<behavior name="SilverlightFaultData.Web.Service1Behavior">
  <serviceMetadata httpGetEnabled="true" />
  <serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
The sample application's Service1 uses this behavior, which then allows the exception to be converted automatically into a FaultException<ExceptionDetail>. The Silverlight 3 client can then check the e.Error argument in its asynchronous completion event handler and take appropriate action, as shown in the code below and in Figure 5: 
if (e.Error != null) {
    ErrorPanel.DataContext = e.Error;
    if (e.Error is FaultException<ExceptionDetail>) {
        var fault = e.Error as FaultException<ExceptionDetail>;
        ErrorPanel.DataContext = fault;
    }
}
fig05.gif
Figure 5 Undeclared FaultException
Undeclared faults show the exception in its raw state with all of the ugly error information, which is obviously not a good idea to show to a user. For this reason, it is not recommended to use undeclared faults in a production application. The managed exceptions can contain internal application information too (sometimes sensitive information). Setting the includeExceptionDetailInFaults to true should only be done when temporarily debugging an application error, and not in production environments. I strongly recommend that the includeExceptionDetailInFaults is set to false for production applications.

Declared Faults
A declared fault is created when the service operation is decorated with a FaultContractAttribute (or a derived type of the FaultContractAttribute). Unlike undeclared faults, declared faults are good for production as they specifically translate an exception's information in code to the fault type. In the Web service, a developer can create the fault type in code and set its properties with information that is appropriate to send to Silverlight. The fault should only be filled with information that the client must know. Any sensitive information (such as credentials) should not be sent to the client in the fault. In the Silverlight client, a developer can write code to look for that type and tell the user something appropriate.
Figure 6 shows the service operation being decorated with the FaultContract attribute with a type of DataFault. The general FaultContract<typeof(ExceptionDetail)> could have been used, though I recommend using a specific custom fault type for the operation. In this case, the operation uses the DataFault type that I created in the sample application. This service operation will fail because the database cannot be found. An exception will be thrown and then caught by the try/catch block, where the exception is read and key information is put into the DataFault before it is thrown. At this point, the DataFault is converted to a SOAP fault and sent back to the Silverlight client with a status code of 200.
 Figure 6 Creating a Declared Fault 
[OperationContract]
[FaultContract(typeof(DataFault))]
public IList<Products> DoWork()
{
    try
    {
        var ctx = new NorthwindEFEntities();
        var query = from p in ctx.Products
                    select p;
        return query.ToList<Products>();
    }
    catch (Exception ex)
    {
        DataFault fault = new DataFault { Operation = Operation.Other, Description = ex.Message };
        throw new FaultException<DataFault>(fault, "because");
    }
}
The DataFault class (shown in Figure 7) defines an Operation property and a Description property. The properties that the fault contains are up to the developer. The properties should represent the key information for the fault so it can be examined by the Silverlight client. The operation is set to a custom enumeration of type Operation (also shown in Figure 7) that will indicate the type of SQL operation that was being performed when the exception occurred. The Description should be set to a custom message and not to the exception message to avoid sending any sensitive information. (The sample application uses ex.Message just for demonstration purposes. I do not recommend passing the exception's Message directly back to the Silverlight client.) The FaultException also accepts a parameter that represents the reason for the exception. In the sample, the reason is set to "because." The reason can be used to help the client classify the cause of the exception.
 Figure 7 DataFault class 
public class DataFault
{
    public Operation Operation { get; set; }
    public string Description { get; set; }
}

public enum Operation
{
    Select,
    Insert,
    Update,
    Delete,
    Other
}
The sample's Service3 has a configuration whose endpoint indicates that the behaviorConfiguration should use the SilverlightFaultBehavior class (this translates the status code from 500 to 200). The configuration is shown here: 
<service
  behaviorConfiguration="SilverlightFaultData.Web.Service3Behavior"
  name="SilverlightFaultData.Web.Service3">
  <endpoint address=""
    behaviorConfiguration="SilverlightFaultBehavior"
    binding="customBinding" bindingConfiguration="silverlightBinaryBinding"
    contract="SilverlightFaultData.Web.Service3" />
  <endpoint address="mex" binding="mexHttpBinding"
    contract="IMetadataExchange" />
</service>
When the service that uses the declared fault is executed, the Silverlight client receives and can read the fault. The following code is executed when the asynchronous Web service operation completes: 
if (e.Error is FaultException<ServiceReference3.DataFault>)
{
    var fault = e.Error as FaultException<ServiceReference3.DataFault>;
    ErrorPanel.DataContext = fault;
}
The Error is checked to see if it is a FaultException of type DataFault. If it is, then its individual properties Operation and Description can be examined. Figure 8 shows the DataFault's custom information displayed directly to the user.
fig08.gif
Figure 8 Examining the Declared Fault
In production applications, a custom fault strategy should be devised to map some exceptions to SOAP faults. The key here is determining the circumstances under which exceptions should be mapped to faults. This depends on whether the client application should be informed of specific information about errors on the server.

Wrapping Up
This article explained how Silverlight 3 applications can benefit from both binary encoding and exception management features. Binary message encoding is a solid choice over basicHttpBinding when using .NET WCF clients, such as Silverlight. Exceptions often contain critical information that can help in debugging an application. This article showed how to surface exception information in both development and production environments, using the Silverlight 3 enhancements.

Send your questions and comments for John to mmdata@microsoft.com" .

John Papa ( johnpapa. net ) is a senior consultant and a baseball fan who spends summer nights rooting for the Yankees with his family. John, a Silverlight MVP, Silverlight Insider, and INETA speaker, has authored several books, including his latest, titled Data-Driven Services with Silverlight 2 (O'Reilly, 2009). He often speaks at conferences such as VSLive!, DevConnections, and MIX.

Datenpunkte
Daten-Leistung und Fault-Strategien in Silverlight 3
John Papa
Codedownload verfügbar aus der MSDN Code Gallery
Den Code Online Durchsuchen
Silverlight-Anwendungen nutzen häufig von Webdiensten für Ihre Daten. Die Leistung der Datenabruf und die Möglichkeit, aussagekräftige Informationen über Ausnahmen abzurufen, die in Web Services auftreten können, sind zwei wichtige Bereiche, die in Silverlight-3 verbessert wurden.
Eine schlechte Leistung kann eine Anwendung Killer sein. Gute Strategien zum Abrufen von Daten aus einem Webdienst können helfen, aber manchmal ist es erforderlich, um ein Objektdiagramm abzurufen, die sehr lange dauern, die von einem Webdienst an einen Client übergeben und sehr groß werden können. Silverlight 3 bietet ein neues Feature, das Daten aus einem Webdienst mit binärer Codierung übergibt und diese kann Leistung deutlich verbessern, wenn große Objektgraphen übergeben.
Viel kann falsche wechseln, wenn Daten zwischen Diensten und Silverlight-Anwendungen übergeben. Dies ist deshalb wichtig, eine gute Strategie für die Behandlung von Ausnahmen, die beim Aufrufen eines Webdienstes auftreten. Silverlight 3 bietet einige Netzwerkverbesserungen, mit denen Entwickler Weitere Optionen, Informationen über verwaltete Ausnahmen von Webdiensten zu übergeben.
Im Artikel dieses Monats werde ich wie binäre Codierung arbeitet, die Auswirkungen zeigen, es auf einer Anwendung Leistung und wie es hat durch in Aktion demonstrieren verhält. Ich führt auch über mehrere Techniken, die nicht deklarierte und deklarierte Fehlern von Windows Communication Foundation (WCF)-Webdiensten zu Silverlight mit Ausnahmeinformationen übergeben verwendet werden können. Zunächst wird demonstriert, was passiert, wenn eine Ausnahme auftritt und zum Hinzufügen von einige schnelle an der Konfiguration Informationen Änderungen während des Debuggens anzeigen. Dann ich erfahren Sie, wie festgelegt, ein Muster strategische Fehlertoleranz übergeben Ausnahme behandeln deklariert Informationen über SOAP-Diensten, mit Fehlern. Der gesamte Code basiert auf der Betaversion 3 von Silverlight und begleitet diesen Artikel online.

Erstellt für Geschwindigkeit
SOAP und XML übergeben als Text schwerwiegend bloats die Nachricht zwischen WCF und Silverlight übergeben wird. Dies kann eine negative Auswirkung auf Leistung in beide Verarbeitung der Daten und die Zeit, die Daten über HTTP übergeben haben. Silverlight-3 enthält die Möglichkeit, eine binäre Nachrichtencodierer mit WCF-Diensten verwenden, die mit Silverlight-3-Clientanwendungen kommunizieren. Binäre Nachrichtencodierer verbessern die Leistung von WCF-Diensten, besonders wenn übergeben große Diagramme Objekte. Die größte Gewinne in Leistung mithilfe des binären Nachrichtencodierung werden realisiert, beim Übergeben von Arrays, Zahlen und Objektgraphen; weniger Gewinne sind mit sehr kleine Nachrichten und Zeichenfolgen gefunden.
Dies ist keine Strategie Komprimierung, so dass keine negativen Auswirkungen auf Leistung für Packen und Entpacken komprimierte Daten. Jedoch binäre Codierung in der Regel die Größe der übergebenen Daten reduzieren. Verringerung der Größe ist nicht gewährleistet, aber sofort offensichtlich ist, bei großen Objektdiagrammen und ganzzahlige Daten. Die Schlüssel Verbesserung gewonnen aus binäre Codierung ist, dass es optimiert wird, um Server Durchsatz zu erhöhen.

Konfigurieren die binäre Codierung
WCF-Dienste können mit der Verwendung von BasicHttpBinding, die Daten als Text über HTTP sendet Silverlight 2-Anwendungen kommunizieren. Bei Verwendung der Vorlage Silverlight-enabled WCF Service Datei –, wird beim Installieren von Silverlight Tools für Visual Studio installiert, um einen WCF-Dienst für Silverlight 2 zu erstellen, die Bindung konfiguriert wurde, BasicHttpBinding verwenden. Diese Datei Vorlage wurde geändert in Silverlight 3, um den WCF-Dienst für binäre Nachrichtencodierer anstelle von Text verwenden konfigurieren.
Die Vorlage Silverlight-enabled WCF Service Datei konfiguriert WCF-Dienst binär-codierte messaging verwenden. Wenn Sie einen vorhandenen WCF-Dienst verwenden, kann es für die binäre Codierung durch Erstellen einer benutzerdefinierten Bindung in der Datei Web.config im Abschnitt Bindungen Nachricht verwenden, konfiguriert werden. Das folgende Codebeispiel zeigt die benutzerdefinierte Bindung mit dem Namen SilverlightCustomBinding, wie er in der <system.serviceModel>-Abschnitt einer Konfigurationsdatei angezeigt wird. Die SilverlightCustomBinding, BinaryMessageEncoding, Verwendung konfiguriert wird dann über seinen Namen in der Dienstendpunktkonfiguration verwiesen. 
<endpoint address="" binding="silverlightCustomBinding"
  contract="MyTestService" />
<bindings>
  <customBinding>
    <binding name="silverlightBinaryBinding">
      <binaryMessageEncoding />
      <httpTransport />
    </binding>
  </customBinding>
</bindings>
Da BasicHttpBinding Meldungen als Text über HTTP sendet, ist es einfach, die Nachrichten über ein Tool wie z. B. Fiddler zu debuggen. Während BasicHttpBinding noch konfiguriert werden kann, können die Vorteile des binären Encoder so sein, dass es die empfohlene Vorgehensweise. Es ist leicht zu hin-und Umschalten zwischen Binärdatei und Text, allein durch Ändern der Config-Datei. Dies ist hilfreich beim Debuggen von WCF-Dienst. Binäre Codierung wird nur von WCF-Dienste und Clients unterstützt. Wenn Sie eine Clientanwendung nicht WCF Ihres WCF-Diensts nutzen, empfiehlt es sich nicht, binäre Codierung verwenden.

Binärdaten oder Textdaten
Die erste Demo zeigt die Unterschiede in Konfiguration und Leistung zwischen BasicHttpBinding und einer binären Nachrichtencodierung zwischen WCF und Silverlight 3. Die Beispielanwendung in diesem Artikel enthaltenen teilt beide Beispiele (Text und Binary) in separate Dienste, die vom selben Silverlight-3-Client aufgerufen werden kann.
Die Konfiguration für diese Dienste in der Datei Web.config der Beispielanwendung ist in Abbildung 1 dargestellt. Die Unterschiede zwischen dem Text und die binäre Codierung Konfigurationen sind fett dargestellt. Beachten Sie, dass der Dienst SpeedService0 der BasicHttpBinding verwendet während SpeedService1 eine CustomBinding mit die Bindungskonfiguration mit dem Namen SilverlightBinaryBinding (im vorherigen Codebeispiel gezeigt.) verwendet
 Abbildung 1 Konfigurieren von Text oder Binär 
<services>
  <service 
behaviorConfiguration="SilverlightFaultData.Web.SpeedServiceBehavior" 
    name="SilverlightFaultData.Web.SpeedService0">
    <endpoint address="" binding="basicHttpBinding" 
      contract="SilverlightFaultData.Web.SpeedService0" />
    <endpoint address="mex" binding="mexHttpBinding" 
      contract="IMetadataExchange" />
  </service>
  <service
behaviorConfiguration="SilverlightFaultData.Web.SpeedServiceBehavior" 
    name="SilverlightFaultData.Web.SpeedService1">
    <endpoint address="" binding="customBinding" 
      bindingConfiguration="silverlightBinaryBinding" 
      contract="SilverlightFaultData.Web.SpeedService1" />
    <endpoint address="mex" binding="mexHttpBinding" 
      contract="IMetadataExchange" />
  </service>
</services>
Die Dienste SpeedService0 und SpeedService1 abrufen beide alle Produkte und jedes Produkt-Kategorie, Lieferanten und Order Details. Die Abfrage (siehe Abbildung 2 ) verwendet das Entity Framework, um das Objektdiagramm abrufen.
 Abbildung 2 Abrufen einer Objekt-Diagramm 
[OperationContract]
public IList<Products> DoWork()
{
    var ctx = new NorthwindEFEntities();
    var query = from p in ctx.Products
                .Include("Categories")
                .Include("Suppliers")
                .Include("OrderDetails")
                select p;
    var productList = query.ToList<Products>();
    return productList;
}
Einer der die besten Aspekte der die Codierung der binären Nachricht ist, dass nur Änderungen in der Konfigurationsdatei gefunden werden. Mit dem Code müssen keine Änderungen vorgenommen werden.
Wenn Sie die Beispielanwendung ausführen, und die Codierungsoption Text (wie in Abbildung 3 dargestellt) aktiviert ist, wird der Dienst, der BasicHttpBinding verwendet, ausgeführt. Das Objektdiagramm zurückgegeben, und verwenden eine HTTP-Überwachungstool wie Fiddler oder FireBug, die Ergebnisse zeigen, dass das Objektdiagramm in Form von Text 4 MB in Größe wurde und 850ms abgerufen hat. Wenn Sie die Codierung die Option Binary auswählen, wird das Objektdiagramm zurückgegeben ist 3 MB und dauerte 600ms zum Abrufen. Dies zwar ein kleines Beispiel mithilfe von ein mittlerer Größe Objektdiagramm aus der Datenbank Northwind, die Ergebnisse werden in einer Zeile mit der Silverlight-Webdienst Team benchmarks . In diesem Beispiel die binäre Codierung verwenden das Objektdiagramm enthält über 2.300 insgesamt Objekten und wird die Größe von 25 % reduziert und ist schneller als die Textcodierung 30 %.
fig03.gif
Abbildung 3 Abrufen der Daten über BasicHttpBinding

Fehlermeldungen sind Daten
Wenn verwalteten Ausnahmen werden in einem Webdienst ausgelöst, Sie können nicht in einer SOAP-Nachricht konvertiert und an eine Silverlight 2-Clientanwendung. Darüber hinaus kann nicht in Silverlight 2 SOAP-Fehler gelesen werden. Diese beiden Probleme erschweren die Debuggen-Webdienste mit Silverlight 2. Da SOAP-Faults mit Silverlight 2 verwendet werden kann, ist eine häufige Fehlermeldung, die meisten Silverlight 2-Entwickler schließlich beim Zugriff auf einen Webdienst der berüchtigte "remote-Server hat einen Fehler zurückgegeben: NotFound," keine pratical Informationen enthält. Die ursprüngliche Ausnahme und die Details sind nicht an den Client Silverlight 2 transportiert wodurch die Webdienste schwierig zu debuggen. Fehlermeldungen enthalten Daten, die häufig als kritisch zu bestimmen, wie die Client-Anwendung reagieren soll. Abbildung 4 zeigt z. B. die Ergebnisse der Aufrufen eines Webdienstes eine Ausnahme ausgelöst, da die Datenbank gefunden werden kann.
fig04.gif
Abbildung 4 Berüchtigten NotFound-Fehler
Wenn die Ausnahme ausgelöst wird, wird ein HTTP-Statuscode 500 an Silverlight zurückgegeben. Der Browser-Netzwerkstapel verhindert, dass Silverlight Antworten mit dem Statuscode 500, lesen, sodass alle enthaltenen SOAP-Fault Informationen für die Silverlight-Clientanwendung nicht verfügbar ist. Auch wenn die Meldung abgerufen werden konnte, kann Silverlight 2 nicht den Fehler wieder in eine verwaltete Ausnahme konvertieren. Diese beiden Probleme wurden in Silverlight-3 behoben.

Übernehmen die Probleme
Behandlung von Ausnahmen mit WCF und Silverlight-3 erfordert diese beiden Probleme bearbeitet. Zuerst muss für die Ausnahme an den Silverlight-Client zurückgegeben werden, ohne den Browser-Netzwerkstack verhindert, dass Silverlight Lesen der Statuscode von 500 etwas geändert werden, mit dem Silverlight die Antwort lesen können. Dies kann durch Ableiten von der BehaviorExtensionElement und implementieren die IEndpointBehavior-Klasse, sodass den Statuscode von 500 zu 200 vor immer eine Fehlertoleranz ändern erreicht tritt ein, und die Dienste für das Verhalten in der Konfigurationsdatei festlegen. Die MSDN-Dokumentation enthält ein WCF-Endpunktverhalten kann dazu verwendet werden und ermöglichen somit Silverlight Clients Zugriff auf den Inhalt des Fehlers. Das folgende Codebeispiel zeigt den speziellen Code in der SilverlightFaultBehavior-Klasse, die den Statuscode konvertiert: 
public void BeforeSendReply(ref Message reply, object correlationState)
{
    if (reply.IsFault)
    {
        HttpResponseMessageProperty property = 
          new HttpResponseMessageProperty();
        // Here the response code is changed to 200.
        property.StatusCode = System.Net.HttpStatusCode.OK;
        reply.Properties[HttpResponseMessageProperty.Name] = property;
    }
}
Die SilverlightFaultBehavior-Klasse kann in der Datei Web.config als Verhaltenserweiterung verwiesen werden, wie im folgenden Codeausschnitt gezeigt: 
<extensions>
  <behaviorExtensions>
    <add name="silverlightFaults"
      type="SilverlightFaultBehavior.SilverlightFaultBehavior,
        SilverlightFaultBehavior, Version=1.0.0.0,
        Culture=neutral, PublicKeyToken=null" />
  </behaviorExtensions>
</extensions>
Mit den SilverlightFaultBehavior an Stelle erhält das zweite Problem Silverlight in der Lage die Fehlertoleranz zu einer verwalteten Ausnahme konvertieren, sodass er gelesen werden kann. Obwohl dies nicht möglich mit Silverlight 2 ist, hat Silverlight 3 jetzt die Möglichkeit zum Verarbeiten von Fehlern. Dies ermöglicht Silverlight 3, um eine Fehlertoleranz und entsprechende Informationen darstellen, die dem Benutzer gelesen, wenn in einem Webdienst eine Ausnahme ausgelöst wird.
Der gesamte Prozess lesen die Ausnahmeinformationen in Silverlight 3 führt aussehen:
1) Ist in einem Webdienst Ausnahme.
2) Der Dienst verwendet die SilverlightFaultBehavior, um den HTTP-Statuscode von 500 auf 200 zu konvertieren.
3) Die Ausnahme in einen SOAP-Fehler konvertiert und an den Silverlight-3-Client übergeben.
4) Des Browsers ermöglicht Silverlight die Nachricht lesen, da ihm einen Statuscode 200.
5) Code in der Silverlight-3-Anwendung überprüft den Typ des Fehlers festzustellen, ob es eine FaultException oder einer FaultException <exceptiondetail> ist.

Nicht deklarierter Fehler
SOAP-basierte WCF-Dienste kommunizieren mithilfe von SOAP-Fault Nachrichten Fehler oder verwalteten Ausnahmen. Daher .NET-verwaltetem Ausnahmen werden in einer SOAP-Fehler an den Client übergeben konvertiert und dann übersetzten wieder zu einem verwalteten Ausnahme.
Fehlern können nicht deklariert oder deklariert und alle sind stark typisiert. Nicht deklarierte Fehlern werden nicht im Vorgangsvertrag angegeben, und sollte nur zum Debuggen verwendet werden. Nicht deklarierte Fehlern zurückgegeben an den Client die Ausnahmemeldung, genau wie es im Webdienst ausgelöst wurde. Um eine nicht deklarierte Fehlertoleranz zu ermöglichen, muss das Config-Element IncludeExceptionDetailInFaults-Attribut auf true festgelegt werden, wie unten dargestellt: 
<serviceDebug> 
<behavior name="SilverlightFaultData.Web.Service1Behavior">
  <serviceMetadata httpGetEnabled="true" />
  <serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
Die Beispielanwendung Service1 verwendet dieses Verhalten zu dem dann die Ausnahme in einem FaultException <exceptiondetail> automatisch konvertiert werden kann. Der Silverlight-3-Client kann dann das e.Error-Argument in den asynchronen Abschluss-Ereignishandler überprüfen und entsprechende Aktion in den folgenden Code und in Abbildung 5 angezeigt werden: 
if (e.Error != null) {
    ErrorPanel.DataContext = e.Error;
    if (e.Error is FaultException<ExceptionDetail>) {
        var fault = e.Error as FaultException<ExceptionDetail>;
        ErrorPanel.DataContext = fault;
    }
}
fig05.gif
Abbildung 5 nicht deklarierte FaultException
Nicht deklarierte Fehlern anzeigen im Rohzustand mit allen die problematischen Fehlerinformationen, die offensichtlich nicht ratsam, anzeigen, um einem Benutzer ist die Ausnahme. Aus diesem Grund nicht empfiehlt es sich, nicht deklarierte Fehlern in einer Produktionsanwendung verwenden. Verwalteten Ausnahmen können Informationen der internen Anwendung zu enthalten (manchmal auch vertrauliche Informationen). Die IncludeExceptionDetailInFaults auf True festlegen sollten nur wenn einen Anwendungsfehler vorübergehend zu debuggen und nicht in Produktionsumgebungen durchgeführt werden. Ich empfehle nachdrücklich, dass die IncludeExceptionDetailInFaults für Produktionsanwendungen auf False festgelegt ist.

Deklarierte Fehler
Deklarierten Fehlertoleranz wird erstellt, wenn der Dienstvorgang mit einem FaultContractAttribute (oder einen abgeleiteten Typ der FaultContractAttribute) ergänzt ist. Im Gegensatz zu nicht deklarierte Fehlern sind deklarierte Fehlern gut für Produktion, wie Sie speziell eine Ausnahme-Informationen im Code in den Typ Fehlertoleranz übersetzen. Im Web Service können Sie ein Entwickler den Fault-Typ in Code erstellen und legen Sie seine Eigenschaften Informationen, die zum Senden an Silverlight geeignet ist. Der Fehler sollte nur mit Informationen gefüllt werden, die der Client kennen muss. Alle vertraulicher Informationen (wie z. B. Anmeldeinformationen) sollte nicht in den Fehler an den Client gesendet werden. Im Silverlight-Client kann ein Entwickler Code zum Suchen nach Typ und dem Benutzer mitteilen einen passenden schreiben.
Abbildung 6 zeigt den Dienstvorgang wird mit dem Attribut FaultContract mit DataFault Typ ergänzt. Allgemeine FaultContract <typeof(ExceptionDetail)> konnte, verwendet wurden Obwohl es empfiehlt sich mit einem bestimmten benutzerdefinierten Fehlertoleranz-Typ für den Vorgang. In diesem Fall verwendet der Vorgang DataFault, die ich in der Beispielanwendung erstellt. Dieser Dienstvorgang schlägt fehl, da die Datenbank gefunden werden kann. Eine Ausnahme wird ausgelöst, und dann abgefangen durch Try-Catch-Block, wobei die Ausnahme wird gelesen und Schlüsselinformationen wird in der DataFault abgelegt, bevor es ausgelöst wird. Zu diesem Zeitpunkt wird die DataFault in einen SOAP-Fehler konvertiert und zurück an den Silverlight-Client mit dem Statuscode 200 gesendet.
 Abbildung 6 erstellen einen deklarierten Fault 
[OperationContract]
[FaultContract(typeof(DataFault))]
public IList<Products> DoWork()
{
    try
    {
        var ctx = new NorthwindEFEntities();
        var query = from p in ctx.Products
                    select p;
        return query.ToList<Products>();
    }
    catch (Exception ex)
    {
        DataFault fault = new DataFault { Operation = Operation.Other, Description = ex.Message };
        throw new FaultException<DataFault>(fault, "because");
    }
}
Die DataFault-Klasse (siehe Abbildung 7 ) definiert eine Operation-Eigenschaft und eine Beschreibung-Eigenschaft. Die Eigenschaften, die der Fehler enthält, werden dem Entwickler. Die Eigenschaften sollten die Schlüsselinformationen für das Problem darstellen, damit er vom Silverlight-Client überprüft werden kann. Der Vorgang wird auf eine benutzerdefinierte Enumeration vom Typ Vorgang (Siehe auch Abbildung 7 ) festgelegt, die den Typ des SQL-Operation angeben wird, die beim Auftreten der Ausnahme ausgeführt wurde. Die Beschreibung sollte auf eine benutzerdefinierte Meldung und nicht auf die Ausnahmemeldung damit vertraulichen Informationen gesendet festgelegt werden. (Die Beispielanwendung ex.Message nur zu Demonstrationszwecken verwendet. Ich empfehlen nicht die Ausnahme Nachricht direkt an dem Silverlight-Client übergeben.) Die FaultException akzeptiert auch einen Parameter, der den Grund für die Ausnahme darstellt. Im Beispiel ist der Grund "wegen." auf festgelegt Der Grund kann damit den Client die Ursache der Ausnahme klassifizieren verwendet werden.
 Abbildung 7 DataFault-Klasse 
public class DataFault
{
    public Operation Operation { get; set; }
    public string Description { get; set; }
}

public enum Operation
{
    Select,
    Insert,
    Update,
    Delete,
    Other
}
Im Beispiel Service3 hat eine Konfiguration, dessen Endpunkt gibt an, dass die BehaviorConfiguration die SilverlightFaultBehavior-Klasse verwenden soll (übersetzt den Statuscode 500 auf 200). Die Konfiguration ist hier dargestellt: 
<service
  behaviorConfiguration="SilverlightFaultData.Web.Service3Behavior"
  name="SilverlightFaultData.Web.Service3">
  <endpoint address=""
    behaviorConfiguration="SilverlightFaultBehavior"
    binding="customBinding" bindingConfiguration="silverlightBinaryBinding"
    contract="SilverlightFaultData.Web.Service3" />
  <endpoint address="mex" binding="mexHttpBinding"
    contract="IMetadataExchange" />
</service>
Wenn der Dienst, der deklarierten Fehlertoleranz verwendet, ausgeführt wird, wird der Silverlight-Client empfängt und die Fehlertoleranz lesen. Im folgende Code wird ausgeführt, bei Abschluss des asynchronen Web Service-Vorgangs: 
if (e.Error is FaultException<ServiceReference3.DataFault>)
{
    var fault = e.Error as FaultException<ServiceReference3.DataFault>;
    ErrorPanel.DataContext = fault;
}
Der Fehler wird geprüft ist eine FaultException des Typs DataFault. Wenn dies der Fall ist, können Ihre einzelnen Eigenschaften Vorgang und Beschreibung untersucht werden. Abbildung 8 zeigt die DataFault benutzerdefinierten Informationen, die direkt mit dem Benutzer angezeigt.
fig08.gif
Abbildung 8 deklarierten Fehler überprüfen
In Produktionsanwendungen sollte eine benutzerdefinierte Fehlertoleranz Strategie Zuordnen von einigen Ausnahmen zu SOAP-Fehler entwickelt werden. Der Schlüssel ist die Bedingungen bestimmen, unter denen Ausnahmen Fehlern zugeordnet werden sollen. Dies hängt davon, ob die Client-Anwendung bestimmte Informationen über Fehler auf dem Server informiert werden sollten.

Umbrechen von
In diesem Artikel wird erläutert, wie Silverlight 3 Anwendungen binäre Codierung und Verwaltungsfunktionen, die Ausnahme profitieren können. Binäre Nachrichtencodierung ist eine solide Wahl über BasicHttpBinding, wenn .NET WCF-Clients, wie Silverlight verwendet wird. Ausnahmen enthalten häufig kritische Informationen, die in das Debuggen einer Anwendung helfen können. In diesem Artikel gezeigt, wie Informationen zur Ausnahme in Entwicklungs- und Produktionsumgebungen Umgebungen, die mithilfe der Silverlight-3-Erweiterungen Oberfläche.

Senden Sie Fragen und Kommentare für John mmdata@Microsoft.com" .

John Papa ( Johnpapa. NET ) ist leitender Berater und ein Fan Baseball, für die Yankees mit seiner Familie rooting Sommer Nächte anfeuert. John, ein Silverlight-MVP, Silverlight Insider und INETA-Sprecher, hat mehrere Bücher, einschließlich seine neuesten verfasst Titel Data-Driven Services with Silverlight 2 (O' Reilly, 2009). Er spricht oft auf Konferenzen wie VSLive!, DevConnections, und MIX.

 

Current Issue

 

 

 

Tip: Click the printer button in your browser toolbar to get the printer friendly version of this article.

 

Page view tracker