Daten- oder Control-orientierte Programmierung

Gastbeitrag von | 22.06.2019

Vor kurzem erreichte mich auf Twitter eine Frage, warum ich anstatt Vanille-JavaScript oder jQuery zu wählen, mich für ein Single Page Application Framework entschieden hatte. Eine tolle Frage, die allerdings auf Twitter durch die Begrenzung der Buchstaben nicht leicht zu beantworten ist. Also dachte ich, ich würde einen alten Post entstauben, den ich vor vielen Jahren geschrieben habe, um das Thema anzusprechen. Vor einiger Zeit hatte ich auch einen Artikel mit dem Titel Die Wahl der “richtigen” JavaScript-Bibliothek geschrieben, der auch einige zusätzliche Ideen beleuchtet.

Grundsätzlich lässt sich jede Art von Frontend-App mit Vanilla JavaScript, jQuery oder einem Single Page Application (SPA) Framework oder einer Bibliothek erstellen. Und wenn wir ehrlich sind, interessiert es die Endanwender wenig, für welche Option sich Entwickler entscheiden. Oder wann wurden Sie von einem Anwender zum letzten Mal gefragt: “Hey Michelle – welche Art von Codierungsplattform haben Sie für diese App verwendet? Erzählen Sie mir auch mehr über die Anwendungsarchitektur!”.

Wenn Sie sich mit Daten- versus Control-orientierter Programmierung beschäftigen, kommt es vor allem darauf an, wie sehr Sie sich auf benutzerdefinierte Programmierung konzentrieren oder Geschäftsprobleme in einer vorhandenen Anwendung lösen wollen. Mit dem Vanille-JavaScript-Ansatz haben Sie “rohen” Zugriff auf das DOM, aber Sie müssen auch alles selbst schreiben, einschließlich Routing, Data-Bindung, HTTP-Aufrufe an den Server, etc. Mit jQuery erhalten Sie eine vereinfachte Möglichkeit, auf das DOM zuzugreifen, Ereignisse zu handhaben, HTTP-Aufrufe zu tätigen, usw., jedoch müssen Sie viel Code schreiben, um andere Szenarien zu managen und Daten abzufragen oder darzustellen. Wenn Sie Unterstützung bei der Data-Binding benötigen, können Sie eine der vielen vorhandenen Bibliotheken wie bspw. KnockoutJS verwenden. Der Aufwand, Code zu schreiben und/oder Daten abzufragen bzw. darzustellen, lässt sich deutlich reduzieren. Und dann gibt es natürlich noch die Single Page Application (SPA) Bibliotheken und Frameworks, die eine Vielzahl von Funktionen sofort einsatzbereit bereitstellen, insbesondere wenn es um die Arbeit mit Daten geht.

Ich ziehe es vor, mit einer gut etablierten und gut unterstützten SPA-Bibliothek/Framework zu arbeiten, egal ob es sich um Angular, React, Vue.js oder etwas anderes handelt. Nachdem ich im Laufe der Jahre viele Frontend-Anwendungen geschrieben habe, habe ich festgestellt, dass es sich nicht lohnt, sich die Zeit zu nehmen, benutzerdefinierten Code zu schreiben (und zu unterstützen), um das zu tun, was viele SPA-Bibliotheken/Framework “out of the box” tun. Das ist natürlich eine sehr subjektive Meinung, aber ich bin zuversichtlich, dass viele Frontend-Entwickler da draußen diese Meinung teilen. Außerdem kann ich unmöglich mit all den verschiedenen Sicherheitsherausforderungen Schritt halten und sicherstellen, dass mein benutzerdefiniertes Framework/Bibliothek für mögliche Hacks verantwortlich ist.

Für mich läuft es wirklich darauf hinaus, ob Sie den gesamten Code schreiben wollen, um mit den Steuerelementen auf Ihrem Bildschirm zu interagieren, oder ob Sie den Daten erlauben wollen, die Anzeige auf dem Bildschirm zu ändern. Es ist eine Entscheidung zwischen “Daten- oder Control-orientierter Programmierung”.

Control-orientierte Programmierung

Das Data-Binding ist ein Schlüsselaspekt der kundenorientierten Programmierung, um die Menge des geschriebenen Codes deutlich zu minimieren, die Wartung zu vereinfachen und letztendlich die Anzahl der Fehler zu reduzieren. Ohne Data-Binding müssen Sie jedes Control in einer Seite mit Code lokalisieren und ihm dann einen Wert zuweisen oder extrahieren – etwas, das ich als “control-orientierte ” Programmierung bezeichne. Hier ist ein bösartiges Beispiel für ein solches Vorgehen (dieser Code ruft geradezu nach einem Refactoring, alleine schon in Bezug auf die vielen Steuerungselemente, die aufgerufen werden:

function loadApprovalDiv()
{
    var subTotal = parseFloat($('#SubTotal').text());
    $('#ClientSubTotal').val(subTotal.toFixed(2));
    var salesTaxRate = parseFloat($('#SalesTaxRate').val()) / 100;
    var salesTaxAmount = (subTotal * salesTaxRate) * .9;
    var deliveryFee = parseFloat($('#DeliveryFee').val());
    var adminFee = ((subTotal + salesTaxAmount + deliveryFee) * .05);
    var total = (Round(subTotal) + Round(salesTaxAmount) +  
      Round(deliveryFee) + Round(adminFee));
    $('#ClientTotal').val(total);
    var deliveryAddress = $('#Delivery_Street').val();
    //See if they entered a suite
    if ($('#Delivery_Suite').val() != '') {
      deliveryAddress += ', Suite ' + $('#Delivery_Suite').val();
    }
    deliveryAddress += ' ' + $('#Delivery_City').val() + ' ' + 
       $('#Delivery_StateID option:selected').text() + ' ' +
       $('#Delivery_Zip').val();
   
    var data = {
      finalSubTotal  : subTotal.toFixed(2),
      finalSalesTax  : salesTaxAmount.toFixed(2),
      finalTotal     : total.toFixed(2),
      deliveryFee    : deliveryFee.toFixed(2),
      adminFee       : adminFee.toFixed(2),
      deliveryName   : $('#Delivery_Name').val(),
      deliveryAddress: deliveryAddress,
      deliveryDate   : $('#Delivery_DeliveryDate').val(),
      deliveryTime   : $('#Delivery_DeliveryTime option:selected')
                         .text(),
      mainItems      : generateJson('Main'),
      accessoryItems : generateJson('Accessory')
    };
    $('#OrderSummaryOutput').html(
      $('#OrderSummaryTemplate').render(data)
    );
}

Wenn Sie sich den Code ansehen, erkennen Sie, dass ein Großteil davon dem Finden von Controls auf der Seite und dem Extrahieren ihrer Werte gewidmet ist. Das funktioniert absolut einwandfrei – schließlich gehen viele Anwendungen diesen Weg. Wenn sich eine Anwendung jedoch auf Steuerelemente und nicht auf Daten konzentriert, wird viel zusätzlicher Code benötigt, was die Sache erschwert, gerade wenn Control-IDs geändert, neue hinzugefügt oder bestehende Steuerelemente entfernt werden. Wenn Sie nur ein paar Controls haben, ist das keine große Sache, aber wenn die Anzahl der Controls wächst, wird es problematisch. Und sobald es sich um clientseitige Programmierung handelt, ist es aus meiner Sicht deutlich sinnvoller, daten-orientierte Anwendungen zu erstellen.

Datenorientierte Programmierung

Ich beziehe mich auf Anwendungen, die ein Data-Binding nutzen, das sich auf die eigentlichen Daten und nicht auf das Schreiben von Code für den Aufruf von Steuerungselementen auf einer bestimmten Seite konzentriert. Ich habe im Laufe der Jahre viele Control-orientierte Anwendungen entwickelt und festgestellt, dass der Übergang zur Erstellung datenorientierter Anwendungen definitiv einen anderen Denkprozess erfordert. Der Schritt zur Entwicklung datenorientierter Anwendungen lohnt sich jedoch und führt nach meiner Erfahrung letztendlich zu besseren Anwendungen. Ich denke, es ist besonders wichtig für Frontend-Anwendungen, die mit JavaScript erstellt wurden.

Wenn Sie bereits ein SPA-Framework / Bibliothek oder eine Data-Binding-Bibliothek verwenden, dann werden Sie den Wert datenorientierter Programmierung kennen. Wenn Sie jedoch neu in dieser Frontend-Welt sind, dann ist datenorientierte Programmierung etwas, das ich Ihnen wärmstens empfehlen würde.

Hier finden Sie sind ein einige (sehr einfache) Beispiele:

Knockout.js

<input data-bind="value: customer.firstName" />

Angular

<input [(ngModel)]="customer.firstName" />

React

<input type="text" value={this.state.customer.firstName} 
  onChange={this.handleChange} />

Vue.js

<input v-model="customer.firstName" />

Diese verschiedenen Codebeispiele behandeln automatisch die Aktualisierung der Zieleigenschaft (in diesem Fall FirstName), wenn sich das Textfeld ändert. Beachten Sie, dass keine ID erforderlich ist und kein weiterer Code existiert. Wenn Sie sich nun ein Formular mit vielen Textfeldern, Radiobuttons, Checkboxen usw. vorstellen, ist es leicht nachzuvollziehen, wie der datenorientierte Ansatz zu viel sauberem Code führt. Darüber hinaus können Sie diesen Ansatz auch verwenden, um Ihre Daten dazu zu bringen, Teile eines Bildschirms ein- und auszublenden, Ereignisse zu verarbeiten und viele andere produktive Aufgaben auszuführen. So führt bspw. ein einfaches Umschalten einer booleschen Eigenschaft von falsch auf wahr zu einem neuen Data-Binding. Das ist geradezu magisch.

Durch die Verwendung einer datenorientierten Bibliothek/Framework können Sie JavaScript-Objekteigenschaften mit Controls verknüpfen und die Controls und Objekteigenschaften automatisch aktualisieren lassen (ein Prozess, der als bidirektionales Binding bezeichnet wird), da Änderungen auf beiden Seiten vorgenommen werden. Das bedeutet, dass Sie keine Selektoren schreiben müssen, um Controls im DOM zu finden und diese zu aktualisieren oder Werte zu übernehmen. Wenn Sie jemals mit Desktop-Entwicklungsframeworks gearbeitet haben, dann sind Sie mehr als wahrscheinlich an diese Art von Funktionalität gewöhnt, und ich wette, dass Sie nicht ohne sie leben können. Data-Binding macht süchtig, sobald Sie es nutzen.

Lange Jahre war ich eine großer Fan von jQuery und Vanilla JavaScript, doch als ich immer mehr Frontend-Anwendungen schrieb, wurde mir klar, dass viel unnötiger Code geschrieben wurde, der durch einen datenorientierten Ansatz eliminiert werden konnte. jQuery und Vanilla JavaScript haben immer noch ihren Platz in einigen Anwendungen (nicht jede Anwendung hat schließlich robuste Datenbindungsanforderungen), aber Optionen zum Erstellen datenorientierter Anwendungen zu nutzen, ist meiner Meinung nach weder im Sinne der Funktionalität noch in Bezug auf Ihren zeitlichen Aufwand empfehlenswert. Die Optionen sind zwar großartig, wenn Sie einen Low-Level-DOM-Zugriff benötigen, aber nicht so toll, wenn eine Anwendung viele Create, Read, Update, Delete (CRUD)-Operationen nutzt. Wenn Sie verstehen, was eine datenorientierte Anwendung wirklich ist und warum sie wichtig ist, dann ist der Einsatz dieser Technik für CRUD-Anwendungen und viele andere Anwendungsarten sinnvoller.

Fazit

Mit SPA-Frameworks/Bibliotheken wie Angular/React/Vue.js und anderen ist das Data-Binding integriert, so dass es ziemlich einfach ist, mit einem datenorientierten Ansatz zu arbeiten. Die Herausforderung in der JavaScript-Welt besteht darin, dass es nicht nur eine “beste” Data-Binding-Option gibt. Es gibt nach wie vor viele verschiedene Skriptbibliotheken/Frameworks mit unterschiedlichen Vor- und Nachteilen. Die große Herausforderung bleibt also darin bestehen, dass Framework / die Bibliothek zu wählen, das für Sie am besten geeignet ist – stellen Sie einfach sicher, dass es datenorientierte Programmierunterstützung integriert hat!

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Der Beitrag von Dan Wahlin ist im Original unter https://blog.codewithdan.com/data-oriented-vs-control-oriented-programming/ erschienen. Mit Zustimmung von Dan Wahlin übersetzen wir verschiedene Beiträge von ihm hier in unserem Blog vom Englischen ins Deutsche. Beiträge im Original finden Sie unter https://blog.codewithdan.com/. In LinkedIn können Sie sich mit ihm unter https://www.linkedin.com/in/danwahlin/ vernetzen.

Dan Wahlin
Dan Wahlin

Dan Wahlin ist Entwickler, Architekt, Technologietrainer, Autor und öffentlicher Redner mit Fachkenntnissen in der Architektur, dem Design und dem Bau von lokal und in der Cloud gehosteten Webanwendungen unter Verwendung verschiedener Technologien (JavaScript, TypeScript, Angular, .NET, C #, ASP.NET) , Node.js, HTML5 / CSS, Docker, Azure, Github / git, Windows / OSX / Linux und mehr). Er ist Autor mehrerer Bücher, verfasste Hunderte von technischen Artikeln und erstellt Videokurse für Pluralsight und Udemy. Dan spricht gerne bei Anwendergruppen, Meetups, Code-Camps und Konferenzen auf der ganzen Welt, darunter Microsoft BUILD und (früher) TechEd, MIX, DevIntersection, AngleBrackets, DevSum, Ng-Conf, Angular U und viele andere.