Wer mit der im SQL Server 2005 / 2008 integrierten .NET-Unterstützung arbeitet, will diese Funktionalitäten recht schnell nicht mehr missen – wird aber über kurz oder lang auch darüber stolpern, dass etwa die Rückgabelänge von Zeichenketten auf 8 KByte beschränkt ist. Das mag zwar nach viel klingen, aber wenn man ein XML-Fragment zurückgeben möchte, stößt man recht zuverlässig an diese Grenze und fängt sich eine TruncationException ein.

Eine gewöhnliche Userdefined Function in C# sieht etwa so aus:

[SqlFunction]
public static SqlString Foo(String input) { ... }

Sowohl Rückgabe, als auch der Übergabeparameter input sind hier auf eine Größe von maximal 8 KByte beschränkt. Wem das nicht ausreicht, der muss das SqlFacet-Attribut verwenden, das sich sowohl oberhalb der Funktion, als auch vor dem Übergabeparameter notieren lässt:

[SqlFunction]
[return: SqlFacet(MaxSize = -1)]
public static SqlString Foo([SqlFacet(MaxSize = -1)] String input) { ... }

Problem gelöst: Die MaxSize-Angabe definiert, dass es keine maximale Größe für den Parameter oder die Rückgabe mehr geben soll. Nach dem erneuten Bereitstellen der Assembly im SQL Server sollte es keine TruncationException mehr geben.

Webseiten sind nicht immer statisch verdrahtet. Manchmal benötigt man eine Möglichkeit, UserControls dynamisch nachzuladen. Mit Hilfe von ein wenig Code geht sowas ohne großen Aufwand.

Gegeben sei ein einfaches UserControl TextDisplay.ascx, das eine TextBox anzeigt oder alternativ den eingegebenen Text darstellt:

<%@ Control Language="C#" ClassName="TextDisplayControl" %>
<script runat="server">
   /// <summary>
   /// Zugriff auf den angezeigten Namen
   /// </summary>
   public String Text
   {
      get
      {
         return tbName.Text;
      }
      set
      {
         tbName.Text = value;
      }
   }

   /// <summary>
   /// Behandelt das PreRender-Ereignis
   /// </summary>
   protected override void OnPreRender(EventArgs e)
   {
      // Überprüfen, ob ein PostBack stattgefunden hat
      if(!IsPostBack)
      {
         // Initial das Eingabefeld anzeigen
         ToggleVisibility(true);
      }

      // Daten binden lassen
      DataBind();

      // Weiter verarbeiten lassen
      base.OnPreRender(e);
   }

   /// <summary>
   /// Schaltet die Sichtbarkeit der PlaceHolder um
   /// </summary>
   private void ToggleVisibility(bool showEnterText)
   {
      // Anzeige umschalten
      phEnterText.Visible = showEnterText;
      phShowText.Visible = !showEnterText;
   }

   /// <summary>
   /// Aktiviert die Texteingabe
   /// </summary>
   protected void EditText(object sender, EventArgs e)
   {
      // Eingabefeld anzeigen lassen
      ToggleVisibility(true);
   }

   /// <summary>
   /// Aktiviert die Textausgabe
   /// </summary>
   protected void ShowText(object sender, EventArgs e)
   {
      // Ausgabefeld anzeigen lassen
      ToggleVisibility(false);
   }
</script>
<asp:PlaceHolder runat="server" ID="phEnterText">
   <div>Ihr Name</div>
   <div><asp:TextBox runat="server" ID="tbName" /></div>
   <div><asp:Button runat="server" ID="tbButtonShow"
      Text="Anzeigen" OnClick="ShowText" /></div>
</asp:PlaceHolder>
<asp:PlaceHolder runat="server" ID="phShowText">
   <div>Hallo, <asp:Label runat="server" Text="<%# tbName.Text %>" /></div>
   <div><asp:Button runat="server" ID="tbButtonEdit"
      Text="Bearbeiten" OnClick="EditText" /></div>
</asp:PlaceHolder>

Dieses Steuerelement verfügt über zwei Buttons, deren Ereignisbehandlungsmethoden ShowText und EditText die Umschaltung der beiden Platzhalter, in denen sich die Eingabe- bzw. Ausgabe-Elemente befinden, steuern. Dabei kommt der Standard-ASP.NET-Ereignisverarbeitungsmechanismus zu Einsatz.

In einer Page oder einem übergeordneten Steuerelement wird dieses Control nun dynamisch geladen. Dabei kommt die Methode LoadControl() der Page- bzw. Control-Klasse zum Einsatz. Diese nimmt als Parameter den relativen oder absoluten Pfad zum zu ladenden Steuerelement entgegen. Wichtig dabei ist, das sich das Steuerelement innerhalb des Applikationsverzeichnisses befinden muss – ein Steuerelement aus einem anderen Verzeichnis lässt sich so nicht laden.

Beim Init-Ereignis des ladenden Steuerelements findet der eigentliche Aufruf von LoadControl() statt. Bezogen auf die Ereignisreihenfolge ist Init eines der sehr am Anfang stehenden Ereignisse und möglicherweise nicht ideal bezogen auf das Auslesen von Informationen aus dem Benutzerkontext (Session), denn dieser steht hier noch nicht zur Verfügung. Soll jedoch die Ereignisbehandlung innerhalb des zu ladenden Steuerelements wie gewohnt ablaufen, ist der Eintritt des Init-Ereignisses der beste Zeitpunkt – spätere Events würden dazu führen, das innerhalb des geladenen Steuerelements unter Umständen keine ordnungsgemäße Abarbeitung der Lebenszyklen stattfinden kann (ViewState wird nicht richtig geladen, Events werden nicht korrekt geworfen, etc.).

Nachdem das Steuerelement geladen worden ist, liegt es als Instanz vom Typ Control vor, ist also eher generischen Charakter. Ist jedoch der Klassenname bekannt, kann die geladene Instanz in den konkreten Typ konvertiert werden. Damit sind sämtliche typspezifische Eigenschaften und Methoden erreichbar und können manipuliert werden.

Zuletzt muss das Steuerelement einem anderen, in der Seite befindlichen Steuerelement zur Anzeige zugewiesen werden. Dies geschieht mit Hilfe der Add()-Methode von dessen Controls-Auflistung.

Der Code einer Seite, die das Steuerelement TextDisplay.ascx lädt und einbindet, sieht letztlich so aus:

<%@ Page Language="C#" %>
<script runat="server">

   /// <summary>
   /// Behandelt das Init-Ereignis der Seite
   /// </summary>
   protected override void OnInit(EventArgs e)
   {
      // Laden des Controls
      Control textDisplay = LoadControl("~/TextDisplay.ascx");

      if(!IsPostBack)
      {
         // Control in den konkreten Typ umwandeln
         TextDisplayControl tdc = textDisplay as TextDisplayControl;

         // Initialen Text setzen
         tdc.Text = "Karsten";
      }

      // Control an den PlaceHolder anfügen
      phData.Controls.Add(textDisplay);

      base.OnInit(e);
   }

</script>
<!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>Eingabeseite</title>
   </head>
   <body>
      <form id="form1" runat="server">
         <h1>Hier können Sie Ihren Namen eingeben</h1>
         <div>
            <asp:PlaceHolder runat="server" ID="phData" />
         </div>
      </form>
   </body>
</html>

Falls Sie sich fragen, woher in Zeile 15 der Klassenname TextDisplayControl stammt: Der wurde in der Control-Deklaration mit Hilfe des Attributs ClassName definiert:

<%@ Control Language="C#" ClassName="TextDisplayControl" %>

Ruft ein Benutzer die Seite im Browser auf, erhält er initial folgende Ausgabe:

Gibt er einen Namen ein und betätigt die Schaltfläche Anzeigen, wird zur zweiten Ansicht gewechselt:

Der Wechsel auf die Eingabeseite zurück geschieht durch Klick auf die Schaltfläche Bearbeiten.

Zusammenfassend bleibt festzuhalten: Steuerelemente lassen sich dynamisch über die Methode LoadControl() nachladen. Sie können anschließend in ihren konkreten Typ konvertiert werden. Wichtig ist, das dieser Prozess so zeitig wie möglich im Lebenszyklus der Seite stattfindet, damit die Ereignisse und Verarbeitungen des dynamisch nachgeladenen Steuerelements korrekt verarbeitet werden können.

Das .NET CF ist eingeschränkt, das weiß man. Diese Einschränkungen betreffen leider auch so alltägliche Dinge, wie etwa LINQ to SQL (geht nicht) oder XSL-Transformationen (geht auch nicht). Stop, Moment, zumindest XSL-Transformationen gehen. Jedenfalls mit einem kleinen Trick.

Bei den meisten Windows Mobile-Geräten ab Version 6 (wenn nicht bei allen) befindet sich nämlich die MSXML-COM-Komponente auf den Maschinchen. Und diese Komponente kann angesprochen werden – nicht jedoch, ohne vorher die Komponente in das .NET CF-Projekt zu importieren. Leider geht das bei COM-Komponenten nicht direkt – aber es gibt den MIDL-Kompiler, der aus einer .idl-Datei eine .tlb-Datei zaubern kann, die sich wiederum als Referenz dem Projekt hinzufügen lässt.

Folgende Schritte müssen Sie ausführen, um MSXML zu verwenden:

1. Öffnen Sie die Visual Studio-Eingabeaufforderung und wechseln Sie in das Verzeichnis [Programme]\Windows Mobile 6 SDK\PocketPC\Include\Armv4i
2. Lassen Sie die tlb-Datei erstellen, indem Sie

   midl /L . msxml2.idl

   eingeben

3. Kopieren Sie die erzeugte msxml2.tlb-Datei in das Verzeichnis Ihrer .NET CF-Applikation
4. Fügen Sie die Datei Ihrem Projekt als Referenz über das "Durchsuchen"-Tab des Verweis-Dialogs hinzu

Nun können Sie mit Hilfe von MSXML auf die gute, alte, herkömmliche Art und Weise mit XML arbeiten:

// Quelle laden
DOMDocument doc = new DOMDocumentClass();
doc.load("source.xml");

// XSL-Stylesheet laden
DOMDocument xsl = new DOMDocumentClass();
xsl.load("style.xsl");

// Transformation durchführen
string html = doc.transformNode(xsl);

Na bitte, geht doch!

Was von Anfang an bei LINQ to SQL gestört hat, ist die scheinbare Notwendigkeit, auf Mappings per Attribut zurückzugreifen. Stellen Sie sich ein klassisches Szenario vor: Es sollen mit den selben LINQ-Statements je nach Situation unterschiedliche Tabellen abgefragt werden (ich habe das zum Beispiel bei einem Kunden, der mit Navision arbeitet). Das geht mit Attributen schlicht nicht. Oder Sie möchten einfach keine Attribute nutzen, die ja eine fixe Verdrahtung mit LINQ to SQL bedeuten würden, was oftmals nicht wünschenswert ist.

Zum Glück gibt es die XmlMappingSource-Klasse. Die erlaubt es, die Mappings in XML-Dateien abzulegen und somit unabhängig von der Klasse zu halten, was in Bezug auf Wartbarkeit und Entkoppelung von Schichten ohnehin deutlich sinnvoller ist.

Die XmlMappingSource-Klasse verfügt über vier statische Methoden:

• FromReader(): Nimmt eine XmlReader-Instanz entgegen
• FromStream(): Erwartet einen Stream
• FromUrl(): Erwartet die Angabe eines URI
• FromXml(): Akzeptiert eine als XML interpretierbare Zeichenkette

Etwas umständlich ist, das nicht mehrere XML-Dateien zugewiesen werden können, aber da kann man sich ggf. mit kleineren Workarounds (Laden mehrerer Dateien, Überführen in ein Gesamt-XML) behelfen.

Um zu verdeutlichen, wie mit dem XML-basierten Mapping gearbeitet kann, soll im folgendenen Beispiel eine einfache Personen-Klasse verwendet werden:

using System;

namespace XML_LINQ_Sample.Model
{
   /// <summary>
   /// Repräsentiert eine Person
   /// </summary>
   public class Person
   {
      /// <summary>
      /// Initialisierung der Klasse
      /// </summary>
      public Person()
      {
         LastChanged = DateTime.Now;
      }

      /// <summary>
      /// Id der Person, Identity in der Tabelle
      /// </summary>
      public int Id { get; set; }

      /// <summary>
      /// Vorname
      /// </summary>
      public string FirstName { get; set; }

      /// <summary>
      /// Nachname
      /// </summary>
      public string LastName { get; set; }

      /// <summary>
      /// E-Mail-Adresse
      /// </summary>
      public string Email { get; set; }

      /// <summary>
      /// Datum der letzten Änderung
      /// </summary>
      public DateTime LastChanged { get; set; }
   }
}

Das Mapping für diese Klasse kann nun wie folgt aussehen:

<Database Name="Samples"
          xmlns="http://schemas.microsoft.com/linqtosql/mapping/2007">

   <!-- Person -->
   <Table Name="Persons" Member="XML_LINQ_Sample.Model.Person">

      <!-- Typ-Definition -->
      <Type Name="XML_LINQ_Sample.Model.Person">

         <!-- ID -->
         <Column Name="Id" Member="Id" IsPrimaryKey="true" IsDbGenerated="true" />

         <!-- Vorname -->
         <Column Name="FirstName" Member="FirstName" />

         <!-- Nachname -->
         <Column Name="LastName" Member="LastName" />

         <!-- Email -->
         <Column Name="EMail" Member="Email" />

         <!-- Letzte Änderung -->
         <Column Name="LastChanged" Member="LastChanged" />
      </Type>

   </Table>

</Database>

Wichtig für dieses Mapping ist die Angabe des korrekten Namensraumes http://schemas.microsoft.com/linqtosql/mapping/2007, da der Inhalt des XML-Dokuments sonst schlicht nicht ausgewertet werden könnte. Die einzelnen Typen werden innerhalb eines Table-Elements in einem Type-Element definiert. Eine Spalte definiert das Column-Element, wobei die beiden Attribute Name und Member Pflichtangaben sind. Zusätzlich werden beim ID-Element die beiden Attribute IsPrimaryKey und IsDbGenerated verwendet. Deren Aufgabe ist es, anzugeben, ob die Spalte den Primärschlüssel der Tabelle repräsentiert (IsPrimaryKey) und ob der jeweilige Wert vom Datenbanksystem automatisch generiert werden soll (IsDbGenerated).

Tipp: Das XML-Dokument sollten Sie als Ressource ihrem Projekt hinzufügen, da dies die Handhabung deutlich erleichtert. In diesem Fall wird es unter dem Namen PersonMapping als Ressource gespeichert.

Innerhalb unseres Programms können Sie nun eine Methode definieren, die diese Ressource lädt und einem DataContext zuweist:

/// <summary>
/// Erzeugt einen DataContext
/// </summary>
private static DataContext GetDataContext()
{
   // ConnectionString-Einstellungen abrufen
   ConnectionStringSettings connStr = ConfigurationManager.ConnectionStrings["Sample"];

   // DbProviderFactory abrufen
   DbProviderFactory factory = DbProviderFactories.GetFactory(connStr.ProviderName);

   // Connection erzeugen lassen
   DbConnection connection = factory.CreateConnection();
   connection.ConnectionString = connStr.ConnectionString;

   // MappingSource definieren
   XmlMappingSource source = XmlMappingSource.FromXml(Resources.PersonMapping);

   // DataContext zurückgeben
   return new DataContext(connection, source);
}

Der "magische Teil" ist die Verwendung einer XmlMappingSource. Ansonsten verhält sich der DataContext, wie Sie es gewohnt sind:

/// <summary>
/// Führt irgendwelche Operationen aus
/// </summary>
public void PerformActions()
{

   // DataContext definieren
   using(DataContext dc = GetDataContext())
   {
      // Schema erzeugen lassen, wenn es
      // noch nicht existiert
      if(!dc.DatabaseExists())
      {
         dc.CreateDatabase();
      }

      // Tabelle referenzieren
      Table<Person> personTable = dc.GetTable<Person>();

      // Datensatz finden
      Person person = (
         from Person p in personTable
         where p.LastName.Equals("Samaschke") &&
               p.FirstName.Equals("Karsten")
         select p).FirstOrDefault();

      // Datensatz gefunden?
      if(null != person)
      {
         // Werte ändern
         person.Email = "name@adresse.de";
         person.LastChanged = DateTime.Now;
      }
      else
      {
         // Datensatz anlegen
         person = new Person();
         person.FirstName = "Karsten";
         person.LastName = "Samaschke";
         person.Email = "name@adresse.de";

         // Datensatz einfügen
         personTable.InsertOnSubmit(person);
      }

      // Änderungen speichern
      dc.SubmitChanges();
   }
}

Mit dem Umweg über die XmlMappingSource schlagen Sie letztlich mehrere Fliegen mit einer Klappe:

• Verwendbarkeit verschiedener Datenbanken oder Datenbanktabellen je nach Szenario
• Verhinderung des Bindens von Klassen an ein bestimmtes O/R-Mapping-Framework
• Bessere Wartbarkeit und Pflegbarkeit Ihres DataLayers

Einziger echter Nachteil ist, das Microsoft diesen Ansatz zwar grundsätzlich dokumentiert, Sie aber bis auf die Klassenbeschreibung der XmlMappingSource und die Definition des XML-Schemas für die Mapping-Dateien keinerlei weitere Unterstützung von Seiten des Anbieters erhalten. Da die Elemente und Attribute jedoch den Standard-LINQ-Code-Attributen entsprechen, können Sie die dort getroffenen Aussagen hier 1:1 übertragen.

Nicht ganz neu, aber ungemein praktisch ist die Idee von Fluent Interfaces. Der Gedanke dahinter ist sehr simpel: Alle Methoden haben eine Rückgabe vom Typ eines definierten Interfaces oder der jeweiligen Klasse. Der Effekt: Die Lesbarkeit wird gesteigert und der Schreibaufwand verringert sich.

Im folgenden Beispiel seien ein Interface IConfiguration und ein Interface IConfigurationFluent definiert, die die gleiche Funktionalität abbilden:

/// <summary>
/// Setzt Konfigurationsinformationen
/// </summary>
public interface IConfiguration
{
   /// <summary>
   /// Breite setzen
   /// </summary>
   void SetWidth(int width);

   /// <summary>
   /// Höhe setzen
   /// </summary>
   void SetHeight(int height);

   /// <summary>
   /// Text setzen
   /// </summary>
   void SetText(string text);

   /// <summary>
   /// Ausführen
   /// </summary>
   void Execute();
}

/// <summary>
/// Setzt Konfigurationsinformationen auf angenehmere Art und Weise
/// </summary>
public interface IConfigurationFluent
{
   /// <summary>
   /// Breite setzen
   /// </summary>
   IConfigurationFluent SetWidth(int width);

   /// <summary>
   /// Höhe setzen
   /// </summary>
   IConfigurationFluent SetHeight(int height);

   /// <summary>
   /// Text setzen
   /// </summary>
   IConfigurationFluent SetText(string text);

   /// <summary>
   /// Ausführen
   /// </summary>
   IConfigurationFluent Execute();
}

Der zusätzliche Definitionsaufwand ist minimal, die Handhabung des Codes nimmt jedoch deutlich zu. Sehen wir uns an, wie man mit dem herkömmlichen Interface arbeitet:

/// <summary>
/// Konfiguriert ein Element auf die "klassische" Art
/// </summary>
public void Configure(IConfiguration config)
{
   // Höhe setzen
   config.SetHeight(20);

   // Breite setzen
   config.SetWidth(40);

   // Text setzen
   config.SetText("Hallo, Welt");

   // Ausführen
   config.Execute();
}

Nichts dagegen einzuwenden. Störend ist nur, das Sie ständig "config" schreiben müssen und Operationen, die zusammen gehören, einzeln durchführen.

Hier ist der funktional gleichwertige Code unter Verwendung des Fluent-Interfaces:

/// <summary>
/// Konfiguriert ein Element auf die "fluente" Art
/// </summary>
public void Configure(IConfigurationFluent config)
{
   // Höhe, Breite, Text setzen und Operation durchführen
   config.SetHeight(20)
         .SetWidth(40)
         .SetText("Hallo, Welt")
         .Execute();
}

Hinweis: Da die implementierten Methoden alle die jeweilige Instanz wieder zurückgeben sollen, muss an deren Ende stets return this; eingefügt werden. Für die Methode SetHeight() könnte eine entsprechende Implementierung also so aussehen:

/// <summary>
/// Setzt die Höhe
/// </summary>
public IConfigurationFluent SetHeight(int height)
{
   // Wert setzen
   this.height = value;

   // Aktuelle Instanz zurück geben
   return this;
}

Wie gesagt: Funktional ist dieser Code gleichwertig, in der alltäglichen Anwendung aber um einiges angenehmer, als der klassische Code. Aus genau diesem Grund wird dieser Ansatz von immer mehr Frameworks eingesetzt – bekanntester Fall ist das NHibernate-Framework, das sehr extensiv davon Gebrauch macht.

Viele XML-Dokumente, die Sie im Web herunterladen oder benutzen können, verfügen über einen Namensraum. Den müssen Sie angeben, wenn Sie bei .NET die XmlDocument-Klasse und deren Methoden SelectSingleNode() bzw. SelectNodes() verwenden möchten, um an die für Sie relevanten Informationen mit Hilfe von XPath-Ausdrücken zu gelangen. Die Frage ist nur, wo und wie man das machen kann, denn das Dokument verfügt zwei über eine Eigenschaft NameTable, die kann jedoch scheinbar nicht sinnvoll verwendet werden.

Stattdessen greifen Sie auf die Klasse XmlNamespaceManager zurück. Deren Konstruktor nimmt als Parameter die NameTable des Dokuments entgegen. Die Methode AddNamespace() erlaubt es Ihnen im Anschluß, die für Sie relevanten Namensräume zu definieren. Dabei ist zu beachten, das so ein Namensraum stets aus zwei Komponenten besteht: Einem Präfix (der eine Abkürzung für den Namensraum darstellt) und dem URI, dem eigentlichen Namensraum. Das Präfix ist dabei – im Vergleich zum originalen Dokument – frei wählbar, der URI muss dem Namensraum im zu verarbeitenden Dokument entsprechen. Sie erkennen die Namensräume stets anhand der xmlns- und xmlns:xx-Attribute, wobei ersteres einen Standardnamensraum darstellt, der ebenfalls per XmlNamespaceManager-Instanz bekannt gemacht werden muss.

Folgendes Beispiel verwendet die XmlNamespaceManager-Klasse um eine Abfrage auf bestimmte Knoten in einem fiktiven Dokument umzusetzen:

// Dokument erzeugen
XmlDocument doc = new XmlDocument();

// Inhalt einladen
doc.Load("http://...");

// Namespace-Manager für die Verwaltung der Namensräume
XmlNamespaceManager manager = new XmlNamespaceManager(doc.NameTable);

// Namensräume anfügen, wichtig sind die URIs
manager.AddNamespace("xs", "urn:sample"); //xmlns:xs="urn:sample"
manager.AddNamespace("xt", "urn:sample2"); //xmlns:xt="urn:sample2"

// Standard-Namensraum anfügen
manager.AddNamespace(string.Empty, "urn:default"); //xmlns="urn:default"

// Abfrage ausführen
XmlNodeList selected = doc.SelectNodes("//dummy[@xt:text='foo']/xs:name");

Die einzige wirkliche Schwierigkeit bei der Arbeit mit Namensräumen im .NET-Framework besteht letztlich nur darin, diese zu identifizieren. Nachdem Sie diese Leistung erbracht haben, sollten die weiteren Schritte problemlos umsetzbar sein.

Angenommen, Sie würden eine Webseite betreiben, die etwa BB-Code oder anderen Pseudocode für Formatierungen von Ausgaben verwendet. Sie hätten dann die unangenehme Aufgabe, ein entsprechendes Umformatieren aller BB-Code-Tags in die entsprechenden HTML-Tags bei jeder Ausgabe vorzunehmen. Da wäre es doch angenehmer, dies zentral erledigen zu lassen.

Für genau diesen Zweck ist die Eigenschaft Filter der HttpResponse-Klasse geschaffen worden. Diese erlaubt es, eine eigene Stream-Implementierung zu definieren, die eine Ausgabe … naja, filtert. Dabei ist das Schwierigste, diese Implementierung zu entwickeln, jedenfalls dann, wenn man nicht weiß, wie man es anstellen soll.

Die Lösung: Einfach die vorhandene Stream-Implementierung im Konstruktor des eigenen Streams übergeben lassen, in einer Instanzvariablen speichern und dann überall verwenden. Der eigene Filter erbt dabei zwingend von der Basisklasse System.IO.Stream und implementiert die abstrakten Methoden dieser Klasse.

Weiterlesen »