Verarbeiten von Ausnahmen auf BLL- und DAL-Ebene in einer ASP.NET-Seite (C#)
von Scott Mitchell
In diesem Tutorial erfahren Sie, wie Sie eine benutzerfreundliche, informative Fehlermeldung anzeigen, falls während eines Einfüge-, Update- oder Löschvorgangs eines ASP.NET Datenwebsteuerelements eine Ausnahme auftritt.
Einführung
Das Arbeiten mit Daten aus einer ASP.NET Webanwendung unter Verwendung einer mehrstufigen Anwendungsarchitektur umfasst die folgenden drei allgemeinen Schritte:
- Bestimmen Sie, welche Methode der Geschäftslogikebene aufgerufen werden muss und welche Parameterwerte sie übergeben werden sollen. Die Parameterwerte können hartcodiert, programmgesteuert zugewiesen oder vom Benutzer eingegebene Eingaben sein.
- Rufen Sie die Methode auf.
- Verarbeiten sie die Ergebnisse. Beim Aufrufen einer BLL-Methode, die Daten zurückgibt, kann dies die Bindung der Daten an ein Datenwebsteuerelement beinhalten. Bei BLL-Methoden, die Daten ändern, kann dies das Ausführen einer Aktion auf Der Grundlage eines Rückgabewerts oder die ordnungsgemäße Behandlung von Ausnahmen, die in Schritt 2 aufgetreten sind, umfassen.
Wie im vorherigen Tutorial gezeigt, stellen sowohl die ObjectDataSource- als auch die Datenwebsteuerelemente Erweiterbarkeitspunkte für die Schritte 1 und 3 bereit. GridView löst beispielsweise sein RowUpdating Ereignis aus, bevor die Feldwerte der ObjectDataSource-Auflistung UpdateParameters zugewiesen werden. Das RowUpdated Ereignis wird ausgelöst, nachdem objectDataSource den Vorgang abgeschlossen hat.
Wir haben bereits die Ereignisse untersucht, die während Schritt 1 ausgelöst werden, und haben festgestellt, wie sie verwendet werden können, um die Eingabeparameter anzupassen oder den Vorgang abzubrechen. In diesem Tutorial widmen wir uns den Ereignissen, die nach Abschluss des Vorgangs ausgelöst werden. Mit diesen Post-Level-Ereignishandlern können wir unter anderem ermitteln, ob während des Vorgangs eine Ausnahme aufgetreten ist, und sie ordnungsgemäß behandeln, indem eine freundliche, informative Fehlermeldung auf dem Bildschirm angezeigt wird, anstatt standardmäßig die Standard-ASP.NET Ausnahmeseite zu verwenden.
Um die Arbeit mit diesen Post-Level-Ereignissen zu veranschaulichen, erstellen wir eine Seite, auf der die Produkte in einer bearbeitbaren GridView aufgeführt sind. Wenn beim Aktualisieren eines Produkts eine Ausnahme ausgelöst wird, wird auf der Seite ASP.NET eine kurze Meldung über der GridView angezeigt, in der erläutert wird, dass ein Problem aufgetreten ist. Jetzt geht‘s los!
Schritt 1: Erstellen eines bearbeitbaren GridView of Products
Im vorherigen Tutorial haben wir eine bearbeitbare GridView mit nur zwei Feldern ProductName und UnitPriceerstellt. Dies erforderte das Erstellen einer zusätzlichen Überladung für die Methode der ProductsBLL Klasse UpdateProduct , die nur drei Eingabeparameter (Produktname, Stückpreis und ID) akzeptierte, im Gegensatz zu einem Parameter für jedes Produktfeld. In diesem Tutorial üben wir diese Technik erneut, indem sie eine bearbeitbare GridView erstellen, die den Namen, die Menge pro Einheit, den Stückpreis und die auf Lager verfügbaren Einheiten des Produkts anzeigt, aber nur den Namen, den Einzelpreis und die vorrätigen Einheiten bearbeiten lässt.
Für dieses Szenario benötigen wir eine weitere Überladung der Methode, die UpdateProduct vier Parameter akzeptiert: Name des Produkts, Stückpreis, Lagereinheiten und ID. Fügen Sie der ProductsBLL-Klasse die folgende Methode hinzu:
[System.ComponentModel.DataObjectMethodAttribute(
System.ComponentModel.DataObjectMethodType.Update, false)]
public bool UpdateProduct(string productName, decimal? unitPrice, short? unitsInStock,
int productID)
{
Northwind.ProductsDataTable products = Adapter.GetProductByProductID(productID);
if (products.Count == 0)
// no matching record found, return false
return false;
Northwind.ProductsRow product = products[0];
product.ProductName = productName;
if (unitPrice == null) product.SetUnitPriceNull();
else product.UnitPrice = unitPrice.Value;
if (unitsInStock == null) product.SetUnitsInStockNull();
else product.UnitsInStock = unitsInStock.Value;
// Update the product record
int rowsAffected = Adapter.Update(product);
// Return true if precisely one row was updated, otherwise false
return rowsAffected == 1;
}
Wenn diese Methode abgeschlossen ist, können Sie die ASP.NET Seite erstellen, die das Bearbeiten dieser vier bestimmten Produktfelder ermöglicht. Öffnen Sie die ErrorHandling.aspx Seite im EditInsertDelete Ordner, und fügen Sie der Seite über die Designer eine GridView hinzu. Binden Sie gridView an eine neue ObjectDataSource, und zuordnen Sie die Select() -Methode der -Methode der ProductsBLL -Klasse GetProducts() und die Update() -Methode der UpdateProduct gerade erstellten Überladung.
Abbildung 1: Verwenden sie die Methodenüberladung, die UpdateProduct vier Eingabeparameter akzeptiert (Klicken Sie, um das bild in voller Größe anzuzeigen)
Dadurch wird eine ObjectDataSource mit einer UpdateParameters Auflistung mit vier Parametern und eine GridView mit einem Feld für jedes Produktfeld erstellt. Das deklarative Markup von ObjectDataSource weist der Eigenschaft den OldValuesParameterFormatString Wert original_{0}zu, was zu einer Ausnahme führt, da die der BLL-Klasse nicht erwartet, dass ein Eingabeparameter mit dem Namen original_productID übergeben wird. Vergessen Sie nicht, diese Einstellung vollständig aus der deklarativen Syntax zu entfernen (oder sie auf den Standardwert festzulegen, {0}).
Analysieren Sie als Nächstes gridView so, dass nur die ProductName, , UnitPriceQuantityPerUnitund UnitsInStock BoundFields enthalten sind. Sie können auch alle Formatierungen auf Feldebene anwenden, die Sie für notwendig erahen (z. B. das Ändern der HeaderText Eigenschaften).
Im vorherigen Tutorial haben wir uns mit dem Formatieren von UnitPrice BoundField als Währung sowohl im schreibgeschützten Modus als auch im Bearbeitungsmodus befasst. Gehen wir hier genauso vor. Beachten Sie, dass hierfür die Eigenschaft von DataFormatString BoundField auf {0:c}, seine HtmlEncode Eigenschaft auf falseund auf ApplyFormatInEditModetruefestgelegt werden musste, wie in Abbildung 2 dargestellt.
Abbildung 2: Konfigurieren des UnitPrice BoundField-Werts für die Anzeige als Währung (Klicken Sie hier, um das bild in voller Größe anzuzeigen)
Das Formatieren von UnitPrice als Währung in der Bearbeitungsschnittstelle erfordert das Erstellen eines Ereignishandlers RowUpdating für das GridView-Ereignis, das die währungsformatierte Zeichenfolge in einen decimal Wert analysiert. Denken Sie daran, dass der RowUpdating Ereignishandler aus dem letzten Tutorial ebenfalls überprüft hat, um sicherzustellen, dass der Benutzer einen UnitPrice Wert bereitgestellt hat. In diesem Tutorial erlauben wir dem Benutzer jedoch, den Preis wegzulassen.
protected void GridView1_RowUpdating(object sender, GridViewUpdateEventArgs e)
{
if (e.NewValues["UnitPrice"] != null)
e.NewValues["UnitPrice"] =decimal.Parse(e.NewValues["UnitPrice"].ToString(),
System.Globalization.NumberStyles.Currency);
}
Unsere GridView enthält ein QuantityPerUnit BoundField, aber dieses BoundField sollte nur zu Anzeigezwecken sein und sollte vom Benutzer nicht bearbeitbar sein. Um dies anzuordnen, legen Sie einfach die BoundFields-Eigenschaft ReadOnly auf fest true.
Abbildung 3: Festlegen des QuantityPerUnit BoundField-Read-Only (Klicken Sie hier, um das bild in voller Größe anzuzeigen)
Aktivieren Sie abschließend das Kontrollkästchen Bearbeitung aktivieren über das Smarttag von GridView. Nach Abschluss dieser Schritte sollte die ErrorHandling.aspx Designer der Seite ähnlich wie Abbildung 4 aussehen.
Abbildung 4: Entfernen Sie alle außer den erforderlichen BoundFields, und aktivieren Sie das Kontrollkästchen Bearbeitung aktivieren (Klicken Sie hier, um das bild in voller Größe anzuzeigen)
An diesem Punkt verfügen wir über eine Liste aller Felder der Produkte ProductName, QuantityPerUnit, UnitPriceund UnitsInStock . Allerdings können nur die ProductNameFelder , UnitPriceund UnitsInStock bearbeitet werden.
Abbildung 5: Benutzer können jetzt einfach Die Namen, Preise und Einheiten von Produkten in Lagerfeldern bearbeiten (Klicken Sie hier, um das bild in voller Größe anzuzeigen)
Schritt 2: Ordnungsgemäße Behandlung DAL-Level Ausnahmen
Während unser bearbeitbares GridView wunderbar funktioniert, wenn Benutzer rechtliche Werte für den Namen, den Preis und die Einheiten des bearbeiteten Produkts auf Lager eingeben, führt die Eingabe illegaler Werte zu einer Ausnahme. Wenn Sie z. B. den ProductName Wert weglassen, wird eine NoNullAllowedException ausgelöst, da die ProductName Eigenschaft in der ProductsRow Klasse AllowDBNull auf falsefestgelegt ist. Wenn die Datenbank ausgefallen ist, wird vom TableAdapter beim Versuch, eine Verbindung mit der Datenbank herzustellen, ausgelöst SqlException . Ohne Maßnahmen zu ergreifen, werden diese Ausnahmen von der Datenzugriffsebene zur Geschäftslogikebene, dann zur seite ASP.NET und schließlich zur ASP.NET Runtime weitergeleitet.
Je nachdem, wie Ihre Webanwendung konfiguriert ist und ob Sie die Anwendung von aus localhostaufrufen oder nicht, kann eine nicht behandelte Ausnahme entweder zu einer generischen Serverfehlerseite, einem detaillierten Fehlerbericht oder einer benutzerfreundlichen Webseite führen. Weitere Informationen dazu, wie die ASP.NET Runtime auf eine nicht ausgeführte Ausnahme reagiert, finden Sie unter Webanwendungsfehlerbehandlung in ASP.NET und dem customErrors-Element .
Abbildung 6 zeigt den Bildschirm beim Versuch, ein Produkt ohne Angabe des ProductName Werts zu aktualisieren. Dies ist der standardmäßige detaillierte Fehlerbericht, der beim Durchlaufen localhostangezeigt wird.
Abbildung 6: Weglassen des Produktnamens werden Ausnahmedetails angezeigt (Klicken, um das bild in voller Größe anzuzeigen)
Während solche Ausnahmedetails beim Testen einer Anwendung hilfreich sind, ist die Darstellung eines solchen Bildschirms für einen Endbenutzer angesichts einer Ausnahme weniger als ideal. Ein Endbenutzer weiß wahrscheinlich nicht, was ein NoNullAllowedException ist und warum es verursacht wurde. Ein besserer Ansatz besteht darin, dem Benutzer eine benutzerfreundlichere Nachricht zu präsentieren, in der erklärt wird, dass probleme beim Versuch aufgetreten sind, das Produkt zu aktualisieren.
Wenn beim Ausführen des Vorgangs eine Ausnahme auftritt, bieten die Post-Level-Ereignisse sowohl im ObjectDataSource- als auch im Datenwebsteuerelement eine Möglichkeit, sie zu erkennen und die Ausnahme vom Sprudeln auf die ASP.NET Runtime abzubrechen. In unserem Beispiel erstellen wir einen Ereignishandler für das GridView-Ereignis RowUpdated , der bestimmt, ob eine Ausnahme ausgelöst wurde, und wenn ja, die Ausnahmedetails in einem Label-Websteuerelement anzeigt.
Fügen Sie zunächst eine Bezeichnung zur seite ASP.NET hinzu, legen Sie die ID -Eigenschaft auf ExceptionDetails fest und löschen Sie die Text -Eigenschaft. Um den Blick des Benutzers auf diese Nachricht zu lenken, legen Sie seine CssClass Eigenschaft auf Warningfest, die eine CSS-Klasse ist, die wir der Styles.css Datei im vorherigen Tutorial hinzugefügt haben. Denken Sie daran, dass diese CSS-Klasse dazu führt, dass der Text des Labels in einer roten, kursiven, fetten und extra großen Schriftart angezeigt wird.
Abbildung 7: Hinzufügen eines Label-Websteuerelements zur Seite (Klicken Sie hier, um das bild in voller Größe anzuzeigen)
Da dieses Label-Websteuerelement nur unmittelbar sichtbar sein soll, nachdem eine Ausnahme aufgetreten ist, legen Sie seine Visible Eigenschaft im Page_Load Ereignishandler auf false fest:
protected void Page_Load(object sender, EventArgs e)
{
ExceptionDetails.Visible = false;
}
Mit diesem Code wird für das Steuerelement auf der ersten Seite der Besuchs- und nachfolgenden Postbacks seine ExceptionDetailsVisible -Eigenschaft auf falsefestgelegt. Angesichts einer Ausnahme auf DAL- oder BLL-Ebene, die wir im GridView-Ereignishandler RowUpdated erkennen können, legen wir die ExceptionDetails Eigenschaft des Steuerelements Visible auf true fest. Da Websteuerelement-Ereignishandler nach dem Page_Load Ereignishandler im Seitenlebenszyklus auftreten, wird die Bezeichnung angezeigt. Beim nächsten Postback rückgängig machen der Page_Load Ereignishandler die Visible -Eigenschaft jedoch wieder zurück zu falseund versteckt sie wieder in der Ansicht.
Hinweis
Alternativ können wir die Notwendigkeit zum Festlegen der ExceptionDetails -Eigenschaft des Steuerelements in Page_Load entfernen, indem wir seine Visible Eigenschaft false in der deklarativen Syntax zuweisen und den Ansichtszustand Visible deaktivieren (die -Eigenschaft auf falsefestlegenEnableViewState). Wir verwenden diesen alternativen Ansatz in einem zukünftigen Tutorial.
Nachdem das Label-Steuerelement hinzugefügt wurde, besteht unser nächster Schritt darin, den Ereignishandler für das GridView-Ereignis RowUpdated zu erstellen. Wählen Sie gridView im Designer aus, wechseln Sie zum Eigenschaftenfenster, und klicken Sie auf das Blitzsymbol, um die Ereignisse von GridView aufzulisten. Es sollte bereits einen Eintrag für das GridView-Ereignis RowUpdating vorhanden sein, da wir zuvor in diesem Tutorial einen Ereignishandler für dieses Ereignis erstellt haben. Erstellen Sie auch einen Ereignishandler für das RowUpdated Ereignis.
Abbildung 8: Erstellen eines Ereignishandlers RowUpdated für das GridView-Ereignis
Hinweis
Sie können den Ereignishandler auch über die Dropdownlisten am Anfang der CodeBehind-Klassendatei erstellen. Wählen Sie in der Dropdownliste links die GridView-Liste und das RowUpdated Ereignis auf der rechten Seite aus.
Beim Erstellen dieses Ereignishandlers wird der CodeBehind-Klasse der ASP.NET Seite den folgenden Code hinzugefügt:
protected void GridView1_RowUpdated(object sender, GridViewUpdatedEventArgs e)
{
}
Der zweite Eingabeparameter dieses Ereignishandlers ist ein Objekt vom Typ GridViewUpdatedEventArgs, das über drei Eigenschaften verfügt, die für die Behandlung von Ausnahmen von Interesse sind:
Exceptionein Verweis auf die ausgelöste Ausnahme; wenn keine Ausnahme ausgelöst wurde, hat diese Eigenschaft den Wert vonnullExceptionHandledein boolescher Wert, der angibt, ob die Ausnahme imRowUpdatedEreignishandler behandelt wurde oder nicht. Wennfalse(standard) die Ausnahme erneut ausgelöst wird, wird die Ausnahme bis zur ASP.NET Runtime erfasst.KeepInEditModewenn festgelegt ist,truedass die bearbeitete GridView-Zeile im Bearbeitungsmodus verbleibt. Wennfalse(Standard), wird die GridView-Zeile wieder in den schreibgeschützten Modus zurückgesetzt.
Unser Code sollte dann überprüfen, ob Exception nicht nullist, was bedeutet, dass beim Ausführen des Vorgangs eine Ausnahme ausgelöst wurde. Wenn dies der Fall ist, möchten wir:
- Anzeigen einer benutzerfreundlichen Nachricht in der
ExceptionDetailsBezeichnung - Angeben, dass die Ausnahme behandelt wurde
- Beibehalten der GridView-Zeile im Bearbeitungsmodus
Mit dem folgenden Code werden diese Ziele erreicht:
protected void GridView1_RowUpdated(object sender, GridViewUpdatedEventArgs e)
{
if (e.Exception != null)
{
// Display a user-friendly message
ExceptionDetails.Visible = true;
ExceptionDetails.Text = "There was a problem updating the product. ";
if (e.Exception.InnerException != null)
{
Exception inner = e.Exception.InnerException;
if (inner is System.Data.Common.DbException)
ExceptionDetails.Text +=
"Our database is currently experiencing problems." +
"Please try again later.";
else if (inner is NoNullAllowedException)
ExceptionDetails.Text +=
"There are one or more required fields that are missing.";
else if (inner is ArgumentException)
{
string paramName = ((ArgumentException)inner).ParamName;
ExceptionDetails.Text +=
string.Concat("The ", paramName, " value is illegal.");
}
else if (inner is ApplicationException)
ExceptionDetails.Text += inner.Message;
}
// Indicate that the exception has been handled
e.ExceptionHandled = true;
// Keep the row in edit mode
e.KeepInEditMode = true;
}
}
Dieser Ereignishandler beginnt mit der Überprüfung, ob e.Exceptionnullist. Wenn dies nicht der Fall ist, wird die ExceptionDetails Eigenschaft von Visible Label auf true und ihre Text Eigenschaft auf "Es gab ein Problem beim Aktualisieren des Produkts" festgelegt. Die Details der tatsächlichen Ausnahme, die ausgelöst wurde, befinden sich in der e.Exception -Eigenschaft des InnerException Objekts. Diese innere Ausnahme wird untersucht, und wenn es sich um einen bestimmten Typ handelt, wird eine zusätzliche, hilfreiche Meldung an die ExceptionDetails Label-Eigenschaft Text angefügt. Schließlich sind die ExceptionHandled Eigenschaften und KeepInEditMode auf truefestgelegt.
Abbildung 9 zeigt einen Screenshot dieser Seite, wenn der Name des Produkts weggelassen wird; Abbildung 10 zeigt die Ergebnisse bei der Eingabe eines unzulässigen UnitPrice Werts (-50).
Abbildung 9: BoundField ProductName muss einen Wert enthalten (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)
Abbildung 10: Negative UnitPrice Werte sind nicht zulässig (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)
Durch Festlegen der e.ExceptionHandled -Eigenschaft auf truehat der RowUpdated Ereignishandler angegeben, dass er die Ausnahme behandelt hat. Daher wird die Ausnahme nicht bis zur ASP.NET Runtime weitergegeben.
Hinweis
Die Abbildungen 9 und 10 zeigen eine ordnungsgemäße Möglichkeit, Ausnahmen zu behandeln, die aufgrund ungültiger Benutzereingaben ausgelöst wurden. Im Idealfall erreicht eine solche ungültige Eingabe jedoch nie die Geschäftslogikebene, da die seite ASP.NET sicherstellen sollte, dass die Eingaben des Benutzers gültig sind, bevor die Methode der ProductsBLL Klasse UpdateProduct aufgerufen wird. In unserem nächsten Tutorial erfahren Sie, wie Sie den Bearbeitungs- und Einfügeschnittstellen Validierungssteuerelemente hinzufügen, um sicherzustellen, dass die an die Geschäftslogikebene übermittelten Daten den Geschäftsregeln entsprechen. Die Validierungssteuerelemente verhindern nicht nur den Aufruf der UpdateProduct Methode, bis die vom Benutzer bereitgestellten Daten gültig sind, sondern bieten auch eine informativere Benutzeroberfläche zum Identifizieren von Dateneingabeproblemen.
Schritt 3: Ordnungsgemäßes Behandeln von BLL-Level Ausnahmen
Beim Einfügen, Aktualisieren oder Löschen von Daten löst die Datenzugriffsebene möglicherweise eine Ausnahme aufgrund eines datenbezogenen Fehlers aus. Die Datenbank ist möglicherweise offline, für eine erforderliche Datenbanktabellenspalte wurde möglicherweise kein Wert angegeben, oder eine Einschränkung auf Tabellenebene wurde möglicherweise verletzt. Zusätzlich zu streng datenbezogenen Ausnahmen kann die Geschäftslogikebene Ausnahmen verwenden, um anzugeben, ob Geschäftsregeln verletzt wurden. Im Tutorial Erstellen einer Geschäftslogikebene wurde beispielsweise der ursprünglichen UpdateProduct Überladung eine Geschäftsregelüberprüfung hinzugefügt. Insbesondere, wenn der Benutzer ein Produkt als nicht eingestellt gekennzeichnet hat, verlangten wir, dass das Produkt nicht das einzige produkt ist, das von seinem Lieferanten bereitgestellt wurde. Wenn gegen diese Bedingung verstoßen wurde, wurde eine ApplicationException ausgelöst.
Fügen Sie für die UpdateProduct in diesem Tutorial erstellte Überladung eine Geschäftsregel hinzu, die verhindert, dass das UnitPrice Feld auf einen neuen Wert festgelegt wird, der mehr als doppelt so hoch ist wie der ursprüngliche UnitPrice Wert. Um dies zu erreichen, passen Sie die UpdateProduct Überladung so an, dass diese Überprüfung ausgeführt wird und eine ApplicationException ausgelöst wird, wenn die Regel verletzt wird. Die aktualisierte Methode folgt:
public bool UpdateProduct(string productName, decimal? unitPrice, short? unitsInStock,
int productID)
{
Northwind.ProductsDataTable products = Adapter.GetProductByProductID(productID);
if (products.Count == 0)
// no matching record found, return false
return false;
Northwind.ProductsRow product = products[0];
// Make sure the price has not more than doubled
if (unitPrice != null && !product.IsUnitPriceNull())
if (unitPrice > product.UnitPrice * 2)
throw new ApplicationException(
"When updating a product price," +
" the new price cannot exceed twice the original price.");
product.ProductName = productName;
if (unitPrice == null) product.SetUnitPriceNull();
else product.UnitPrice = unitPrice.Value;
if (unitsInStock == null) product.SetUnitsInStockNull();
else product.UnitsInStock = unitsInStock.Value;
// Update the product record
int rowsAffected = Adapter.Update(product);
// Return true if precisely one row was updated, otherwise false
return rowsAffected == 1;
}
Mit dieser Änderung führt jede Preisaktualisierung, die mehr als das Doppelte des vorhandenen Preises ist, dazu, dass ein ApplicationException ausgelöst wird. Genau wie die Ausnahme, die von der DAL ausgelöst wird, kann diese BLL-ausgelöste ApplicationException im GridView-Ereignishandler RowUpdated erkannt und behandelt werden. Tatsächlich erkennt der RowUpdated Code des Ereignishandlers, wie er geschrieben wurde, diese Ausnahme ordnungsgemäß und zeigt den -Eigenschaftswert der ApplicationException-Eigenschaft Message an. Abbildung 11 zeigt einen Screenshot, wenn ein Benutzer versucht, den Preis von Chai auf 50,00 USD zu aktualisieren, was mehr als das Doppelte seines aktuellen Preises von 19,95 USD ist.
Abbildung 11: Die Geschäftsregeln lassen Preiserhöhungen nicht zu, die den Preis eines Produkts mehr als verdoppeln (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)
Hinweis
Im Idealfall würden unsere Geschäftslogikregeln aus den UpdateProduct Methodenüberladungen in eine gemeinsame Methode umgestaltet. Dies bleibt als Übung für den Leser.
Zusammenfassung
Während des Einfüge-, Aktualisierungs- und Löschvorgangs waren sowohl das Datenwebsteuerelement als auch die ObjectDataSource feuervor- und post-level-Ereignisse beteiligt, die den tatsächlichen Vorgang gebucht haben. Wie in diesem Tutorial und im vorherigen Tutorial gezeigt, wird bei der Arbeit mit einem bearbeitbaren GridView-Ereignis das GridView-Ereignis RowUpdating ausgelöst, gefolgt vom ObjectDataSource-Ereignis Updating , an dem der Aktualisierungsbefehl für das zugrunde liegende Objekt von ObjectDataSource ausgeführt wird. Nach Abschluss des Vorgangs wird das ObjectDataSource-Ereignis Updated ausgelöst, gefolgt vom GridView-Ereignis RowUpdated .
Wir können Ereignishandler für die Ereignisse vor der Ebene erstellen, um die Eingabeparameter oder die Ereignisse nach der Ebene anzupassen, um die Ergebnisse des Vorgangs zu überprüfen und darauf zu reagieren. Ereignishandler nach der Ebene werden am häufigsten verwendet, um zu erkennen, ob während des Vorgangs eine Ausnahme aufgetreten ist. Angesichts einer Ausnahme können diese Ereignishandler nach der Ebene die Ausnahme optional selbst behandeln. In diesem Tutorial haben wir erfahren, wie Sie eine solche Ausnahme behandeln, indem Sie eine benutzerfreundliche Fehlermeldung anzeigen.
Im nächsten Tutorial erfahren Sie, wie Sie die Wahrscheinlichkeit von Ausnahmen aufgrund von Datenformatierungsproblemen (z. B. eingabe eines negativen UnitPrice) verringert. Insbesondere sehen wir uns an, wie Validierungssteuerelemente zu den Bearbeitungs- und Einfügeschnittstellen hinzugefügt werden.
Viel Spaß beim Programmieren!
Zum Autor
Scott Mitchell, Autor von sieben ASP/ASP.NET-Büchern und Gründer von 4GuysFromRolla.com, arbeitet seit 1998 mit Microsoft-Webtechnologien. Scott arbeitet als unabhängiger Berater, Trainer und Autor. Sein neuestes Buch ist Sams Teach Yourself ASP.NET 2.0 in 24 Hours. Er kann unter mitchell@4GuysFromRolla.comoder über seinen Blog erreicht werden, der unter http://ScottOnWriting.NETzu finden ist.
Besonderer Dank an
Diese Tutorialreihe wurde von vielen hilfreichen Prüfern überprüft. Lead Reviewer für dieses Tutorial war Liz Shulok. Möchten Sie meine bevorstehenden MSDN-Artikel lesen? Wenn dies der Fall ist, legen Sie eine Zeile unter abmitchell@4GuysFromRolla.com.