Ist es eine gute Idee, eine Architektur zu entwerfen, die denkt, dass die Benutzerschnittstellenklassen durch eine Befehlszeilenschnittstelle ersetzt werden können?

92

In Code Complete, Seite 25, heißt es, dass es eine gute Idee ist, die regulären Benutzerschnittstellenklassen einfach durch eine Befehlszeilenklasse zu ersetzen.

Was ist mit den Problemen, die das Testen mit sich bringen kann?

Lohnt sich diese zusätzliche Arbeit wirklich für Web- und Mobilprojekte? Was ist mit kleinen und mittleren Projekten? gelten die gleichen regeln? Was ist, wenn Ihr Design dadurch komplexer wird?

Julio Rodrigues
quelle
2
In Perl sind genau dies Tools wie MooseX :: Getopt und Plack :: Handler :: CLI .
Ether
4
Wenn Sie Ihr Programm zuerst mit einer CLI erstellen, kann die Benutzeroberfläche darüber gelegt werden, was eine viel größere Flexibilität bietet als eine Benutzeroberfläche, die tief in das Programm eingebettet ist. Dies gilt auch für Webdienste.
zzzzBov
28
Immer ist ein starkes Wort.
Mark Canlas
8
Bitte beachten Sie das Originalzitat: "Die Architektur sollte modularisiert werden, damit eine neue Benutzeroberfläche ersetzt werden kann, ohne die Geschäftsregeln zu beeinträchtigen und Teile des Programms auszugeben. Die Architektur sollte es beispielsweise ziemlich einfach machen, a Gruppe interaktiver Schnittstellenklassen und schließen Sie eine Gruppe von Befehlszeilenklassen an. " CC sagt also nicht, dass Sie sich darauf vorbereiten sollten, eine GUI durch eine Befehlszeile zu ersetzen, sondern dass die Architektur das Ändern der Benutzeroberfläche ermöglichen soll. Das GUI-> Kommandozeilen-Ding ist nur ein Beispiel.
sleske
2
@Vandell Ich habe die zweite Ausgabe von Code Complete und diese wird auf Seite 25 nicht erwähnt. Auf welche Ausgabe beziehen Sie sich?
JW01

Antworten:

43

Die Möglichkeit, Funktionen unter verschiedenen Schnittstellen (z. B. GUI vs CLI vs REST) wiederzuverwenden, ist nicht immer erforderlich, aber es ist schön, ein System zufällig wiederverwenden zu können, da andere Benutzer neue Möglichkeiten finden, mit ihm zu interagieren.

Dies hat einige Nachteile, die gewichtet werden müssen:

  1. Es werden zusätzliche Abstraktionsebenen benötigt (manchmal sogar Ebenen). Obwohl diese Schichten eine gute technische Praxis sind, verursachen sie zusätzliche Kosten bei der Entwicklung, was möglicherweise nicht zu einer Verringerung des Aufwands in anderen Bereichen (z. B. Wartung, Wiederverwendung, Tests) führt. Es lohnt sich also, ein wenig darüber nachzudenken.
  2. Strömung, die für ein Medium optimal ist, kann für andere schrecklich sein. Wenn die Funktionalität zur Unterstützung einer GUI entwickelt wurde, ist sie möglicherweise zu gesprächig für das Web . Nicht jede Funktionalität lohnt sich in jedem Medium.
  3. Es ist eine Falle, einen generischen Konverter zwischen Diensten und Benutzeroberfläche zu definieren, sodass man den Servicevertrag definieren und automatisch (oder so weit wie möglich) die Benutzeroberfläche für alle Medien ableiten kann. Viele Projekte haben zu viel Mühe damit verschwendet, solche Frameworks zu erstellen und jede mögliche Anpassung vorzunehmen, wenn sich die Anforderungen ändern.

Nach meiner Erfahrung hat sich die Implementierung solcher Schichten jedoch immer gelohnt. In einigen Fällen gelang es mir, Systeme rechtzeitig bereitzustellen, da wir einige Wochen vor dem Fälligkeitsdatum die Medien (z. B. von der Integration von Webservices zur Benutzeroberfläche) austauschen mussten.

Daniel Yokomizo
quelle
2
Wie andere Kommentare angemerkt haben, sollte dies die Codekohäsion erhöhen und die Kopplung verringern. Beides sollte Ihren Code einfacher und einfacher zu testen machen. Flow ist eher ein GUI-Konzept und sollte normalerweise in keiner anderen Funktionalität vorhanden sein.
BillThor
Ich kann nicht glauben, dass dies noch nicht erwähnt wurde, aber dies ist die Essenz der Model-View-Controller-Architektur. Der Punkt ist, in der Lage zu sein, Ansichten und Controller nach Belieben auszutauschen, um die Kopplung zu verringern, wie @BillThor sagt. Dies ist der beste Anwendungsfall für MVC.
Rudolf Olah
110

Abgesehen vom Testen besteht der offensichtliche Vorteil dieses Ansatzes darin, dass Ihr Projekt automatisierbar und skriptfähig ist . Wenn ich in der Lage bin, Befehlszeilenbefehle an ein Programm zu senden, kann ich ein Skript schreiben, um komplizierte Aufgaben viel einfacher (und zuverlässiger!) Auszuführen, als ich ein Makro erstellen könnte, um dasselbe auf einer GUI zu automatisieren.

Ob sich das wirklich lohnt oder nicht, hängt natürlich ganz davon ab, ob Sie viele Benutzer haben, die Ihr Programm automatisieren möchten oder nicht.

Mason Wheeler
quelle
12
Viele Anwendungen verwenden ein Plugin-Modell für die Skripterstellung. Normalerweise wird das Objektmodell verfügbar gemacht und zum Schreiben der Skripte wird eine Sprache wie Python verwendet. Ich glaube nicht, dass Befehlszeilenparameter für eine nicht triviale App funktionieren.
Softveda
Ein weiterer Vorteil kann die Auffindbarkeit sein. Die Strg-Umschalt-P-Funktion von Sublime Text ist ein fantastisches Beispiel dafür. Wenn ich eine undurchsichtige Funktionalität möchte, anstatt die Menüs durchsuchen zu müssen, gebe ich einfach ein, wie ich denke, dass es aufgerufen wird, und ich kann den Befehl (und die Verknüpfung) sehen und ihn sofort ausführen.
Adam Iley
OpenDJ, ein Open-Source-LDAP-Server auf Java-Basis, ist ein gutes Beispiel dafür: Die Befehlszeile für jede Änderung, die Sie an der Benutzeroberfläche vornehmen, ist im Bestätigungsdialogfeld verfügbar.
Franck
1
@ Marnixv.R .: Gesten sind lediglich eine bequeme Möglichkeit, eine Aktion auszuführen, die durch einen Befehl angegeben werden kann, z. B. 'Zoom in 35.73N 118.23W'. Eine Zeichnung könnte als Befehl eingegeben werden, obwohl dies unpraktisch wäre. Trotzdem denke ich, dass eine bequem skriptfähige Benutzeroberfläche sehr nützlich ist und nur sehr wenig Arbeit erforderlich ist, um eine zu erstellen.
Kevin Cline
7
+1: Ein weiterer wichtiger Vorteil ist, dass die Benutzeraktionen auf einfache Weise protokolliert werden können, wodurch die Reproduktion von Produktionsproblemen vereinfacht wird.
Kevin Cline
81

Es ist keine zusätzliche Arbeit, nur eine andere Arbeit. Wenn Sie es richtig machen, wird es nicht nur nicht komplexer, sondern auch einfacher, da Sie gezwungen sind, Ihr Design zu entkoppeln. Unabhängig davon, ob Sie die CLI tatsächlich implementieren oder nicht, ist Ihr Entwurf besser geeignet, um dies zu ermöglichen.

Karl Bielefeldt
quelle
4
-1 für mehrere völlig falsche Aussagen. Natürlich wird es dadurch komplexer. Es ist immerhin eine zusätzliche Anforderung / Funktion.
Boris Yankov
@BorisYankov Ich denke, er meinte "kompliziert" statt "komplex" - sie klingen ähnlich und haben eine überlappende Bedeutung, so dass sie gelegentlich leicht zu verwechseln sind
Izkata
43

Ein wichtiger Vorteil, der nicht erwähnt worden zu sein scheint, ist, dass dies eine strikte Entkopplung der Benutzeroberfläche vom zugrunde liegenden Code erzwingt . Ein wesentlicher Vorteil dabei ist , dass es bedeutet , dass , wenn Sie brauchen , um signifikant die GUI zu ändern (sagen iOS Standards OSX Standards oder eine grafische Maschine zu einem anderen), das ist alles Sie ändern müssen, da der zugrundeliegende Code ist nicht abhängig von das Layout der Benutzeroberfläche. Es kann nicht sein, denn wenn es so wäre, würden die Kommandozeilen-Tools nicht funktionieren.

Darüber hinaus ist die Automatisierung von Tests ein entscheidender Vorteil.

deworde
quelle
Korrigieren Sie mich , wenn ich falsch liege, aber von einer GUI zu einem anderen gewechselt wird noch erhebliche Arbeit in Bezug auf die Formularvalidierung / zeigt Fehlermeldungen erfordern würde, Event - Handler Einstellung usw.
Klicken Sie Upvote
5
Ja, aber all diese Überprüfungen sind Teil einer guten Benutzeroberfläche, von der ich gesagt habe, dass Sie sie ändern müssen. Der Backend-Code, der (zum Beispiel) den aktuellen Status des Benutzerkontos, den Algorithmus für die Suche nach Elementen, die spezifischen Spielregeln usw. speichert. Der Schlüssel ist, dass ich von der maus- / tastaturbasierten Benutzeroberfläche auf wechseln muss Auf der Touchscreen-Benutzeroberfläche eines Spiels sollte es mir weiterhin möglich sein, dieselbe Back-End-Engine für die Verarbeitung von Kampfberechnungen und Punktzahlen zu verwenden, sodass ich mich darauf konzentrieren kann, neue Ereignishandler zu schreiben, die dasselbe zugrunde liegende System verwenden.
Deworde
2
Das ist übrigens gar nicht so einfach. Ich hasse es, Ereignishandler zu schreiben und Validierungscode viel mehr zu bilden als Geschäftscode. (obwohl ich Ihnen zustimme, dass sie so
entkoppelt werden
2
@ClickUpvote In gewissem Umfang hängt es davon ab, wie Sie Ihre GUI implementieren. Eine wirklich dünne GUI, die nur ValueChanged-Nachrichten an eine Support-Klasse sendet und als Antwort darauf ValueValid / ValueInvalid-Nachrichten empfängt, ist viel einfacher auszutauschen als eine, die die gesamte Validierung in OnTextboxChanged-Ereignissen durchführt.
Dan Neely
@ClickUpvote Ich stimme dir zu, deshalb möchte ich mich auf das konzentrieren können, was ich unverfälscht mag, oder dem, was ich hasse, meine volle Aufmerksamkeit schenken, damit ich so schnell wie möglich damit fertig bin.
Deworde
17

Ja, das ist fast immer eine gute Idee.

Wenn Sie diesem Ansatz folgen, haben Sie wahrscheinlich keine Geschäftslogik oder keinen Datenzugriff in demselben Thread wie die GUI und hinter einigen GUI-Handlern. Allein in diesen Grund lohnt es sich zu investieren.

Coder
quelle
2
Was wäre der Vorteil davon, wenn Sie zB einen Texteditor schreiben?
Nikie
5
@nikie Da Sie beispielsweise Ihre WYSIWIG-Texteditoransicht durch eine Front-End-Ansicht ersetzen könnten, die auf Klartext oder Markups basiert. Solange dieselben Informationen an das zugrunde liegende Modell übergeben werden, funktioniert Ihre vorhandene Infrastruktur weiterhin.
Deworde
5

Ich denke, es ist eine gute Idee. Die Möglichkeit, ein zweites Befehlszeilen-Front-End zu schreiben, beweist letztendlich, dass die Geschäftslogik vollständig von einer bestimmten Anwendungsserver-Architektur entkoppelt ist.

Tulains Córdova
quelle
5

Die einzige Gefahr, die ich dabei sehe, ist, dass der Benutzer normalerweise andere Teile der Benutzeroberfläche durchqueren muss, um zu einem bestimmten Teil der Benutzeroberfläche zu gelangen.

Wobei der Entwickler einfach die Benutzeroberfläche direkt ausführen kann. Ich habe Situationen erlebt, in denen ein Entwickler ein Benutzerproblem nicht reproduzieren konnte, bis er das Produkt tatsächlich verwendet hat.

Berücksichtigen Sie dies also auch beim Erstellen von Tests.

Simon O'Doherty
quelle
3

Schreckliche Ratschläge.

Es ist ein bisschen yagni (du wirst es nicht brauchen).

Das Anzeigen einer Befehlszeilenschnittstelle ist nicht dasselbe wie das Strukturieren Ihrer App in einer Weise, die Unit-Tests unterstützt oder mit einem Teil von SOLID oder einer von mir empfohlenen Programmierpraxis übereinstimmt.

Es funktioniert nicht für eine Benutzeroberfläche, die einfach nicht für eine Befehlszeilenschnittstelle geeignet ist. MS Paint ist eine wirklich einfache Anwendung, aber wie würden Sie in jeder Situation einen Vorteil darin sehen, sie über eine Befehlszeile steuern zu können?

Es würde Ihnen nicht helfen, Skripte zu implementieren. Es würde tatsächlich jeden Fortschritt in diese Richtung behindern.

Das einzig Positive ist, dass es auf Seite 25 auftaucht, sodass Sie zumindest gewarnt werden, dass der Rest des Buches vielleicht ... stinkt. Ich habe es vor langer Zeit gelesen und mochte es nicht, also bin ich voreingenommen.

Ian
quelle
1
Einverstanden +100000000
4
Skriptfähiges MSPaint klingt tatsächlich sehr nützlich.
RoundTower
IMO die beste Antwort. Seitdem ich das Mantra "YAGNI nicht implementieren" befolge, habe ich viel mehr Zeit, mich auf die eigentliche Arbeit zu konzentrieren, und ich habe sogar noch genug Zeit, um viel zu experimentieren. Der Versuch, im Voraus clever zu sein, hat mir gezeigt, dass der Kunde die meiste Zeit eine andere Erweiterung wünschte als zuvor erwähnt, sodass keine Zeit für etwas verschwendet wurde, das nicht benötigt wurde.
topskip
PSPaint + Befehlszeilenschnittstelle = AutoCAD
Vorac
-1 (wenn ich könnte) Beachten Sie, dass nicht "eine CLI sowie eine GUI implementieren" steht; Es heißt "Für die Implementierung einer alternativen Benutzeroberfläche wie einer CLI sorgen".
Mark Hurd
2

Aufbauend auf dem, was Mason Wheeler gesagt hat, macht es die Interaktion mit einer Anwendung über eine Befehlszeile sehr einfach, Aufgaben zu automatisieren.

Dies ist besonders nützlich beim Testen.

Um ein praktisches Beispiel zu geben: Wenn ich automatisierte Tests für eine Anwendung ausführen möchte, möchte ich die Anwendung möglicherweise automatisch installieren. Dazu übergebe ich möglicherweise die folgenden Parameter "myApplication.exe / silentinstall".

Ich kann es so programmieren, dass bei Angabe dieser Befehlszeilenoption eine Installation im Hintergrund ohne das GUI-Installationsprogramm ausgeführt wird. Alle Eingaben in das Installationsprogramm (z. B. das Installationsverzeichnis) können möglicherweise aus einer XML-Datei entnommen werden.

Nehmen Sie ein anderes Beispiel. Die GUI von Microsoft Test Manager (im Lieferumfang von Visual Studio enthalten) ermöglicht Benutzern das Starten von Testläufen über die GUI-Oberfläche, bietet jedoch auch eine Befehlszeilenschnittstelle, über die dasselbe getan werden kann (mithilfe einer Kombination aus Befehlszeilenschaltern und Eingaben). Dies bedeutet, dass ich ein PowerShell- oder DOS-Skript zusammenstellen kann, um das Starten von Tests zu automatisieren, und dann eine geplante Aufgabe erstellen kann, damit die Skripts möglicherweise jede Nacht ausgeführt werden.

Einige Anwendungen verfügen über Befehlszeilenoptionen, die festlegen, dass eine Anwendung mit bestimmten Optionen geöffnet werden soll (z. B. kann die Anwendung mit "/ maximize" in einem maximierten Fenster geöffnet werden).

Es gibt viele Szenarien, in denen eine Befehlszeilenschnittstelle zum Einsatz kommen könnte. Dies sind nur einige Beispiele.

U / min
quelle
1

Beachten Sie den Satz noch einmal: "[Es ist eine gute Idee, die regulären Benutzerschnittstellenklassen einfach durch eine Befehlszeile zu ersetzen". Es bedeutet nicht, dass Sie eine CLI schreiben müssen, nur, dass Sie es einfach tun können.

Es heißt also, dass Ihre Benutzeroberfläche vom Rest des Codes entkoppelt sein sollte.

José Dinuncio
quelle
2
Ich denke, Sie wollten einen Kommentar abgeben, oder?
Julio Rodrigues
1

Es kommt darauf an, und wenn ich sage, dass es darauf ankommt, geht es nicht nur darum, ein paar Randfälle zu haben, sondern es ist sehr abhängig von der Anwendung und der Zielgruppe. Angenommen, wir entfernen Spiele aus der Gleichung, dann gibt es immer noch eine Vielzahl von Anwendungen, die Sie möglicherweise schreiben, wenn ein Befehl wie dieser unwahrscheinlich ist oder niemals implementiert wird. Aus der Vogelperspektive fällt wahrscheinlich jede Anwendung, die auf eine mobile Umgebung (z. B. iOS, Android usw.) abzielt, unter diese Überschrift.

In Anbetracht dessen ist es unwahrscheinlich, dass im allgemeinen Softwarebereich für Anwendungen, die stark von der Visualisierung abhängig sind (z. B. PowerPoint, Maya usw.), jemals eine Befehlszeilenersetzung implementiert wird. Tatsächlich ist es im Fall von Grafiksoftware wie Maya eine gute mentale Übung, festzustellen, wie eine vollständige und ordnungsgemäße Befehlszeilenversion funktionieren würde, und dies ist möglicherweise vom Standpunkt des Benutzers aus nicht möglich. Somit ist klar, dass es definitiv übliche Anwendungen gibt, bei denen es unwahrscheinlich ist, dass eine befehlsähnliche Schnittstelle jemals gesehen wird oder wünschenswert ist, selbst wenn Skripten für die Anwendung wünschenswert sein könnten.

Wenn wir uns als Nächstes die vorgeschlagene Form vom Standpunkt der allgemeinen Softwarearchitektur ansehen, kann ich sehen, wo es sinnvoll wäre, sich regelmäßig die Frage zu stellen: "Wie kann ich ohne die Benutzeroberfläche auf diese Funktion zugreifen?" Wenn dies nicht möglich ist und keine direkte Interaktion mit dem Benutzer stattfindet (z. B. Gesteneingabe), besteht im Allgemeinen die Gefahr, dass die Gesamtarchitektur verbessert werden muss. Um das Testen zu vereinfachen, sollten Sie in der Lage sein, direkt auf Befehle zuzugreifen, ohne die Benutzeroberfläche zu durchlaufen, auch wenn sie möglicherweise nicht über eine Befehlszeile aufgerufen werden. Dies bedeutet im Allgemeinen, dass eine solide API vorhanden sein muss und theoretisch eine gute API den Zugriff über die Befehlszeile oder die Benutzeroberfläche ermöglichen sollte. Darüber hinaus auf lange Sicht,

Letztendlich denke ich, dass das, worauf der Vorschlag abzielt, Sinn macht (dh, Sie sollten eine gute API haben und Ihre Benutzeroberfläche darauf aufbauen), aber die Wortauswahl war möglicherweise etwas besser, um den Punkt zu verdeutlichen .

rjzii
quelle
1
Ich bin im Allgemeinen nicht anderer Meinung, aber eine der großen Stärken von Maya ist die Tatsache, dass es tatsächlich eine sehr starke Skript-API hat (ursprünglich MELScript, jetzt Python).
jwd
@jwd - Maya ist ein Beispiel, das ich ausgewählt habe, weil ich es vor ein paar Jahren verwendet habe. Vielleicht Bryce, obwohl es nicht so gut weiß?
rjzii
0

Es hängt davon ab, ob.

Oft partitionieren wir unsere Programme als model / view / controller oder model / view / view / model. Es scheint, dass das Modell den Zugriff über die Befehlszeile zulassen sollte, aber ich bin mir über den Controller nicht so sicher. Natürlich wird die Ansicht ersetzt.

Ein gewisser Unterschied kann aufgrund der Werkzeugkette bestehen. Code Complete ist ein Microsoft Press-Buch. Verwenden Sie also möglicherweise Microsoft-Technologien für diese GUI? In diesem Fall gibt es möglicherweise ein Kontrollkästchen, wenn Sie die App zum Anzeigen von Schnittstellen über COM oder DCOM erstellen. Bei einigen Microsoft-Technologien sind die Ressourcentabellen und die Nachrichtenübermittlung meiner Meinung nach ziemlich eng mit allem verknüpft, was die Assistenten für einen schnellen Prototyping-Prozess bieten. Ich denke, es wird besser, aber wenn Sie MFC oder Formulare beibehalten, kann es ein bisschen weh tun.

In einigen Fällen handelt es sich bei Ihrem GUI-basierten Programm möglicherweise um einen Wrapper um eine Verwaltungsschnittstelle oder es verfügt über so wenig eigene Logik, dass über die Befehlszeilenschnittstelle nicht viel gesteuert werden kann. Das Erstellen einer separaten Konsolen-App ist möglicherweise schneller und lässt Sie dennoch das Wesentliche skripten, testen oder verwenden.

Der entscheidende Punkt, denke ich, ist, dass der Vorschlag keine Regel ist. Wenn Sie dem folgen, sollten Sie einfachere Tests für Einheiten und Abnahmen oder eine Fallback-Oberfläche erhalten, wenn Sie oder ein Kunde es vielleicht vorziehen, zu tippen, anstatt zu klicken. Wenn es sich auszahlt, tun Sie es. Viel Glück.

DeveloperDon
quelle
4
-1: Code Complete ist ein sprachunabhängiges Buch über Programmierhandwerk.
Deworde
1
Er hat nie etwas anderes gesagt.
Klicken Sie auf "Upvote
Und seine Frage bezog sich speziell auf die Entwicklung der Benutzeroberfläche ... Ihr Standpunkt Herr Deworde?
Ian
0

Es hängt davon ab, wie nützlich das Kommandozeilenprogramm wäre. Einige Dinge, wie das Zeichnen einer Route auf einer Karte oder das Spielen eines 3D-Spiels, eignen sich einfach nicht für eine Befehlszeilenschnittstelle. Aber andere Dinge, wie System-Tools, sind von der Kommandozeile aus viel besser als von einer GUI aus, und zwar aus dem einfachen Grund, dass sie per Skript erstellt werden können.

Dr. Richard Hipp sagte einmal, sein ideales GUI-Betriebssystem sei ein leerer Desktop mit einem Symbol zum Öffnen von Befehlsfenstern und einem weiteren Symbol zum Öffnen eines Webbrowsers. Mir geht es fast genauso. Wenn es als Befehlszeilenprogramm nützlich und nicht zu schwierig wäre, es so zu erstellen, würde ich es tun. Die GUI könnte ein völlig separates Programm sein, das möglicherweise von jemand anderem erstellt wurde!

GlenPeterson
quelle
Warum eignet sich das Zeichnen einer Route auf einer Karte nicht für die CLI-Automatisierung? So etwas PlotRoute(startPoint, endPoint)ist ziemlich unkompliziert.
Mason Wheeler
@ MasonWheeler - Ich glaube, es wäre eher wiePlotRoute(startPoint, endPoint, chart)
Fabricio Araujo
0

Heutzutage (zumindest für Java) scheinen früher oder später alle Programme früher oder später einen Webdienst (SOAP oder Ajax oder beides) hinzuzufügen. Also im Allgemeinen denke ich ja so, aber ein Web-Service-Front-End ist wahrscheinlicher als eine Befehlszeile, wenn Sie eine bessere mentale Metapher wollen ... und eine wahrscheinlicher.

ArtB
quelle
0

Es gibt eine andere Sichtweise. Anstatt davon auszugehen, dass eine Befehlszeile der einzige Weg ist, warum nicht davon ausgehen, dass stattdessen die Sprachsteuerung verwendet wird? Ein völlig anderes Paradigma ist dann erforderlich.

Bevor Jobs Apple übernahm, wurden sehr ausgefeilte Sprachsteuerungsmechanismen untersucht. Apple hat dies zugunsten von Dingen wie Siri unterdrückt.

Seufzer.

Populär und offensichtlich sind sie nicht immer die Besten.

Siajanai
quelle
Einer der Hauptgründe für die Befehlszeile besteht darin, die Funktionalität der Software testen und skripten zu können. Es kann etwas umständlich sein (oder zumindest schwerfällig), Audioclips unserer Stimmen aufzunehmen, um die Software zu testen oder ein Stapelskript auszuführen.
0

Das ist im Allgemeinen eine gute Idee, ja.

By-Metapher, Menschen können dies als eine Form von RESTful Design denken. ... es ist per se nicht so, dass eine typische (G) Benutzeroberfläche komplexe mehrstufige Transaktionen wie die Kontoerstellung beinhalten könnte.

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

Ich habe einmal eine Drag'n'Drop-UI-Metapher im Browser programmiert. Sehr komplexe Interaktionsregeln im Back-End , damit sich das UX natürlich anfühlt. Ich habe das gelöst, indem ich die Site zu einer API gemacht habe und die GUI eine vollständige App war, die Ereignisse nach einer Aktion generierte. Ein Modul hat diese Ereignisse abgefangen und sie in einem Timer zu API-Aufrufen gebündelt (aus Gründen der Netzwerkeffizienz).

Das Ergebnis war ein vollständig RESTful-Kernsystem. Das zweite Ergebnis war, dass ich eine Schnittstelle für Dritte hatte, die ich mit Hilfe von Zugehörigkeitsprofilen gemäß dem Geschäftsmodell offenlegen konnte.

NewAlexandria
quelle
-1

Ein Vorteil ist, dass Sie gezwungen sind, über den Fluss der Benutzeroberfläche aus der Benutzerperspektive nachzudenken. (Was versuche ich zu erreichen? Welchen Kontext muss ich einrichten? In diesem Kontext, wie erreiche ich das Ziel?)

Es gibt einen großen Unterschied zwischen "Bankkonto erstellen" und "ms-Word-Dokument schreiben". Auch wenn Sie keine CLI erstellen, kann dies nur unter Berücksichtigung des erforderlichen "CLI-Kontexts" einen Mehrwert schaffen. Modelle leben nicht nur im Geschäftsobjektmodell!

Aswidi
quelle