Camel Ende vs EndeChoice - nicht die übliche Abfrage

Question

Erstens, ja, ich habe gesucht, und, ja, ich habe das gleiche Apache-Dokument gelesen, jedes einzelne Punkte. :-) Ich denke, es gibt ein wenig Verwirrung und ich denke, ich weiß eine Antwort, also lassen Sie mich ein Beispiel von dem, was ich für richtig hielt, auslegen, folgen Sie dem, was ich denke, die Antwort ist. Vielen Dank. Oh, und ich weiß, dass einige der endChoice() Zeilen nicht unbedingt notwendig sind und dass Camel es herausfinden wird, aber ich mag die Blöcke sauber zu skizzieren, es sei denn, es gibt einen Grund, sie nicht zu benutzen.

.choice() 
    .when(X1) 
     // do stuff 
     .choice() 
      .when(Y) 
       //do more stuff 
      .endChoice() // close inner when block 
     .end() // close inner choice block 
    .endChoice() // close first outer when 
    .when(X2) 
     // do other stuff 
    .endChoice() // close second outer when 
.end() // close outer choice 

mein ursprünglicher Blick auf dem API So, dachte ich, dass das Ende() zum Schließen Dinge wie Wahl und Split war und dass EndChoice() war Wahl Optionen wie, wann und ansonsten zum Schließen. Es sieht eher so aus, als wäre letzteres ein end(), das eine ChoiceDefinition zurückgibt. Was den Namen ein wenig besser macht.

Aber wenn ich das Ende() mit der Aufschrift 'close innere Auswahl Block' herausnehmen, bedeutet dies, dass ich weiter zur nächsten Zeile, einem endChoice(). Schließt dies den inneren Auswahlblock? Vorausgesetzt, dass das when (X2) immer noch innerhalb des when (X1) Blocks ist. Also denke ich, dass ich das Ende() durch ein endChoice() ersetzen muss, anstatt es zu entfernen. So wäre das Ergebnis wie folgt aussehen:

.choice() 
    .when(X1) 
     // do stuff 
     .choice() 
      .when(Y) 
       //do more stuff 
      .endChoice() // close inner when block 
     .endChoice() // close inner choice block 
    .endChoice() // close first outer when 
    .when(X2) 
     // do other stuff 
    .endChoice() // close second outer when 
.end() // close outer choice 

Das ist also die Möglichkeit, dies in Camel zu behandeln? Oder gibt es einen einfacheren Weg, den ich gerade vermisse? Vielen Dank für Ihre Zeit.

Answer 1

kurze Antwort: Ich werde mich auf diese nennen so sonst niemand hat, ist die Antwort, dass Sie es tun falsch und sollte nicht verschachtelt Möglichkeiten.

LANGE ANTWORT: Ich erbte eine komplizierte Route Builder und versuchte, es zu reinigen, um es klarer zu machen. Aber das Begradigen und Einfügen von beiden Enden() oder endChoice() hat einfach die Dinge kaputt gemacht. Und, ja, der obige Fix hat immer noch Dinge kaputt gemacht. Ich verstand nicht, wie Camel wusste, in welchen Block er gehen musste. Forschung und versuchen, gute Beispiele für die Verschachtelung zu finden, fuhr schließlich die Tatsache nach Hause, dass Camel nicht wirklich für die Verschachtelung Wahlen entworfen ist. Es erlaubt es, aber aufgrund von Einschränkungen in Java, tut es das nicht gut. Also habe ich versucht, meine verschachtelten Entscheidungen zu entfernen. Während dies möglich gewesen wäre, hätte es hässlich überflüssig conditionals gemeint, wie:

Nur würde Mine mindestens eine andere Ebene gehabt haben. Weiteres Nachdenken und Nachdenken über Dinge, die ich gelesen hatte, brachten das zweite bisschen Erleuchtung. Der Hauptpunkt von Camel ist die Regie von Routen. Der Block jeder Wahl sollte nur den Prozess auf eine Route zeigen. Es sollte nicht gedacht, verarbeitet oder so etwas sein. Am Ende wird unsere Gruppe refactoring sein, um den Großteil der Logik vom Route Builder zu einer Bean zu entfernen. Das Design, auf das wir hinarbeiten werden, ist etwas Einfaches:

from(uri) 
    .bean(class, method) // do any processing 
    .choice() 
     .when(header("result").isEqualTo("A") 
      .to(routeA) 
     .endChoice() 
     .when(header("result").isEqualTo("B") 
      .to(routeB) 
     .endChoice() 
     .when(header("result").isEqualTo("C") 
      .to(route) 
     .endChoice() 
     .end() 

Mein Rat an Sie ist, Verschachtelung zu vermeiden. Besonders komplizierte. Sie können es zum Laufen bringen, aber Sie können es nicht vertrauen, wenn Sie später Änderungen vornehmen müssen. Wenn Sie versucht sind, geschachtelte Auswahlmöglichkeiten zu verwenden, prüfen Sie, was Sie erreichen möchten, und entscheiden Sie, ob es wirklich in einen Routenersteller gehört.