Andere Art, dass Typ() in eckigen Dart

Question

Ich habe das eckige Dart Tutorial und ich habe eine Frage dazu.

Um einen Typ für dependecy Injektion zu erklären, ich habe dies zu tun:

class MyAppModule extends Module { 
    MyAppModule() { 
    type(RecipeBookController); 
    } 
} 

Und so weiter für alle Arten.

In einer großen App können Sie Hunderte eingeben, so dass es eine seltsame Art ist, alle Typen zu deklarieren.

Gibt es eine andere Möglichkeit, dies zu tun?

Danke.

Answer 1

Sie können Reflektion verwenden, um die Typen zu sammeln. Bitte fügen Sie einen Kommentar hinzu, wenn Sie weitere Informationen zu diesem Ansatz benötigen (ich versuche, Reflektionen in Web-Apps zu vermeiden).

EDIT
Reflexion arbeiten kann, aber wenn man Sonderfälle beginnen wird es sehr schnell unleserlich.
Wenn Sie DI verwenden, haben Sie oft Situationen, in denen der Konstruktor Ihrer Klasse ein Objekt vom Typ InterfaceX erfordert und Sie angeben möchten, welche der Klassen, die die Anforderung erfüllen (die Schnittstelle implementieren), tatsächlich injiziert werden soll. Dann fangen Sie an, Sonderfälle mit Reflektion zu codieren.
Mit type(InterfaceX, implementedBy: Y); ist immer super lesbar.
EDIT END

Ich weiß nicht, ob Sie dies als eine Verbesserung sehen, aber was wir taten

mehr Module erstellen und mit install

zu MyAppModule (und ich habe in mehreren Projekten gesehen) fügen Sie

siehe zum Beispiel bei
- https://github.com/akserg/angular.dart.ui/blob/master/lib/accordion/accordion.dart
- https://github.com/akserg/angular.dart.ui/blob/master/lib/angular_ui.dart

accordion.dart

class AccordionModule extends Module { 
    AccordionModule() { 
    type(AccordionComponent); 
    type(AccordionHeadingComponent); 
    type(AccordionGroupComponent); 
    value(AccordionConfig, new AccordionConfig()); 
    } 
} 

angular_ui.dart

class AngularUIModule extends Module { 
    AngularUIModule() { 
    install(new AlertModule()); 
    install(new AccordionModule()); // the above module 
    install(new ButtonModule()); 
    install(new CarouselModule()); 
    install(new CollapseModule()); 
    install(new DropdownToggleModule()); 
    install(new ProgressbarModule()); 
    install(new RatingModule()); 
    install(new TabsModule()); 
    install(new TimeoutModule()); 
    install(new TransitionModule()); 
    install(new ModalModule()); 
    } 
} 

Answer 2

Hier sind meine Gedanken, als jemand relativ neu in Winkel dart sind. Das beantwortet deine Frage nicht direkt, aber ich hoffe, es ist nützlich.

Erstens Es wird allgemein als "schlecht" angesehen, Globals in der Programmierung zu verwenden. Wenn Sie jedoch mit einem Framework beginnen, haben Sie keine Zeit, alle Best Practices zu lernen. Da Ihre App klein ist, ist es in Ordnung, ein paar Globals zu verwenden. Schließlich refaktorieren Sie, wenn Sie bessere Praktiken lernen, aber Sie sollten beim Erstellen einer kleinen App ein paar Abkürzungen verwenden. Bei Websites sind Routes effektiv globale Variablen, aber selbst auf einer großen Site haben Sie nur ein paar Hundert, bevor Sie die Site in mehrere Sites aufteilen. Ähnliches gilt für IMO-Typen.

Typen sind effektiv wie globale Variablen in einem Programm zu haben.Dies liegt daran, dass es nur ein HTML-DOM gibt und Selektoren in diesem Dom daher andere Selektoren kennen müssen, um eine Kollision zu vermeiden. (selectors sind wie globals in gewisser Hinsicht - selbe mit css - obwohl wir Selektoren für verschiedene Typen in verschiedenen Ansichten wiederverwenden könnten, würde das die css-Beziehung durcheinanderbringen und auch eine zusätzliche Komplikation hinzufügen, wenn versucht wird, die html-Quelle zu lesen und auf den Dart zurückzukommen Code (Sie müssten entscheiden, welche Ansicht aktiv ist etc., und dann, wenn Sie sich entscheiden, die Selektoren zusammen in die gleiche Ansicht zu ziehen, werden die Dinge komplexer, wenn Sie einen von ihnen umbenennen müssen)). Um Selektoren zu vermeiden, die mit Selektoren kollidieren, müssen wir vermeiden, dass Typen mit Typen IMO kollidieren. Arten effektiv als Globals zu haben ist möglicherweise der sauberste Weg, dieses Problem mit dem aktuellen Zustand von HTML zu lösen.

Auch weil einzelne Seite apps nicht zu groß sein sollte, ermutige ich "flat code" gegenüber "nested code", obwohl es gut ist, Balance zu haben. Während Komponenten von Single-Page-Anwendungen möglicherweise komplex sind mit viel Code, glaube ich nicht, dass Sie so viele Arten benötigen. 100 Arten sollten überschaubar sein. Sobald Sie mehr als das bekommen, ist es wahrscheinlich eine gute Idee, eine neue Anwendung zu erstellen. Sonst ist Ihre Single-Page-App wahrscheinlich zu kompliziert für die Benutzer und lädt langsam usw.