Wie Sie richtig importieren/exportieren von Klassen in eckigen Module?

Diese Frage kommt aus dem Kontext von Enterprise Anwendung.

Von allen Büchern, die ich gelesen habe-und online-Proben, die ich gesehen habe über angular-Anwendungen, jedes mal, wenn wir eine Klasse erstellen (Komponente, service, Organisation, etc.) wir exportieren Sie auf die Typ-definition, und dann direkt importieren Sie Sie, wo immer wir benötigen eine Referenz (ähnlich wie mit namespaces in C#) unabhängig der beiden Klassen gehört zu der gleichen oder verschiedene Winkel-Module.

Ex:

//In 'Commons/logger.service.ts'
export class LoggerService { ... }

//In 'Core/common.service.ts'
export class CommonService { ... }

//In 'Products/' module
import { LoggerService } from '../Commons/logger.service'
import { CommonService } from '../Core/common.service'

export class ProductComponent { ... }

Ich angefangen, einen (großen) enterprise-application-Projekts und bemerkte ein Ansatz, den ich noch nie zuvor gesehen hatte, Sie erstellten Dateien zu sammeln jede Art von Klasse (service, Organisation, Methode, parameter, Komponenten -) Export jeder von Ihnen, exportieren Sie jede dieser Dateien auf das entsprechende Winkel-Modul-Datei, und dann, anstatt den Import der Typ direkt aus dem Typ der Datei, führen Sie den Import aus der angegebenen Modul.

Vorherigen Beispiel würde verwandelt werden, so etwas wie dieses:

//In 'Commons/logger.service.ts'
export class LoggerService { ... }

//In 'Commons/services.ts'
export * from './logger.service.ts'
export * from './other.service.ts'
export * from './another.service.ts'

//In 'Commons/commons.module.ts'
export * from 'services.ts'
export * from 'entities.ts'
/* ... */


//In 'Products/' module
import { LoggerService, OtherService } from '../Commons/commons.module'

export class ProductComponent { ... }

Gegeben, dass dieser Ansatz ist viel Ausführlicher als die zuvor und die, die es provoziert peinliche Ergebnisse in einigen Fällen (zyklische Referenz-Warnung, wenn das importieren von Klassen innerhalb des gleichen Moduls)

Meine Fragen sind:

Welche Vorgehensweise wird empfohlen, sich von einem guten design oder beste Praktiken Perspektive?
Ist dieser Ansatz besser als die früheren? Warum? Für welche Fälle?
Warum dieser Ansatz nicht eingeführt, auf die wichtigsten Literatur-und Quellenangaben (eckige online-docs, kantige, Bücher, ...)?
Was sind die vor-und Nachteile dieses Ansatzes.

Ich Schätze, dass, wenn Sie zirkuläre Abhängigkeiten, dieser Ansatz ermöglicht Ihnen, richtig zu Steuern, in welcher Reihenfolge die Module geladen sind
Ich denke, möchten Sie vielleicht zu suchen in einem Gemeinsamen Modul in Ihrer Anwendung, die Importe und Exporte. Dieses gemeinsame Modul kann dann importiert werden, in anderen Modulen, wie gebraucht. Hier finden Sie einige Winkel-Dokumentation: Winkel.io/guide/sharing-ngmodules
Dieser Ansatz ist ideal für das sammeln gemeinsamen die Einfuhren um Doppelarbeit zu vermeiden. Was ich hier spreche, ist eine interne Richtlinie, die auf mein Unternehmen, in dem, Wann immer Sie benötigen einen geben, anstatt Sie zu importieren direkt von der Datei, die Sie importieren muss es vom Modul, ebenso, wenn Sie exportieren eine neue Art, müssen Sie Folgen alle der "Export-Hierarchie" erwähnt, auf der Beispiele. Ich persönlich denke, das ist over-engineering, Probleme zu lösen, die möglicherweise nicht vorhanden in den ersten Platz. Das ist, warum ich bin auf der Suche nach der Meinung einiger Experten auf dem Thema.
Ich sehe, was Sie reden jetzt. Mein Fehler, habe ich falsch verstanden, der mittlere Abschnitt erklären Ihr Ziel.
Ich weiß nicht, die Antwort ... aber ich Frage mich, was der "Baum schütteln" würde, tun Sie dies, wenn Sie immer verlangen, dass alles von allem?
In der Regel, dass sollte nicht der Fall sein, hauptsächlich werden Sie Referenz-Typen, die auf dem common und core-Modul von anderen Modulen, aber es ist selten für die Arten, die zwischen verschiedenen und unabhängigen, Module referenzieren sich gegenseitig. Dieser Ansatz scheint zu sein, genau das gleiche, wie wenn du nur den Import der Dateitypen direkt aus Ihren Dateien, nur dass IMO, wir erschweren den Prozess, um es sich "besser organisiert", es macht Sinn... aber ich denke, nur die over-engineering.

InformationsquelleAutor mdarefull | 2018-03-01

10

Dies ist ein Konzept, bekannt als ein barrel-Datei. Diese Dateien machen das importieren von Klassen bequemer. Das Winkel-team nicht bringen es bis in Ihre docs, aber es ist nicht ein Konzept, um Winkel allein. Es scheint eine bewährte Praxis im Typoskript, Sie zu benutzen.

Wenn Sie ein kleineres Projekt, Sie kann nicht viel von einem Vorteil für die Erstellung dieser Dateien, aber Sie kommen in super hilfreich bei der Arbeit an größeren Projekten mit mehreren team-Mitgliedern. Im folgenden sind einige der Vorteile/Nachteile, die ich bin mir dessen bewusst.

Pro: Weniger Wissen Erforderlich, Um Die Modul-Interna

Wenn eine Komponente haben muss, um einen Verweis auf etwas, es nicht haben sollte, zu wissen, welche genaue Datei der Klasse, etc. ist in. Wenn man nicht Fass das Zeug in einem Modul, dann ist jeder anderen Datei außerhalb des Moduls müssen genau wissen, welche Datei (einschließlich der sub-Pfad) enthält dieses Element. Wenn Sie den Lauf der Elemente in einem einzigen Modul barrel, müssen Sie einfach wissen, was Moduls ist es aus. Dies gibt Ihnen auch den Vorteil, refactoring-Modul nicht, sodass Sie die stellen Sie sicher der Pfad wird aktualisiert, wenn die Datei bewegt (die Werkzeuge kann oder kann nicht helfen, mit diesem).
```
//without barrel files
import { Class1 } from 'app/shared/module1/subpath1/subpath2/class1.service';

//using barrel files
import { Class1 } from 'app/shared/module1';
```
Pro: Explizite Export Außerhalb Modul

Ein weiterer Vorteil ist, dass ein Modul kann enthalten eine Reihe von Klassen, Schnittstellen, etc. das sind wirklich nur dazu genutzt werden, um innerhalb dieses Moduls. Durch die Schaffung eines barrel-Datei für ein Modul, teilen Sie anderen devs wissen was gemeint ist außerhalb des Moduls. Zusätzlich, Sie ließ Sie wissen genau, welche Elemente es sind, verwendet werden, so brauchen Sie nicht, um zu jagen, um Sie zu finden eine Schnittstelle, die Sie benötigen (wieder, Ihre Werkzeuge können oder können nicht dabei helfen).
```
//export these items from module as others need to have references to these
export { ExampleModule } from './example.module';
export { ExampleService } from './example.service';
export { ExampleInterface } from './example.model';

//these also exist in module but others don't need to know about them
//export { ExampleComponent } from './example.component';
//export { Example2Service } from './example2.service';
//export { ExampleInterface2 } from './example.model';
```
Pro: Sauberer Importe

Dem endgültigen nutzen, den ich erwähnen werde ist, dass es hilft, zu reinigen Ihre Importe. Es wird nicht nur machen Sie mehr klar, was Elemente kommen von dem, was Module, es hilft auch, um die from Teil Ihrer import-viel kürzer als die Sie nicht brauchen, um die traverse nach unten sub-Verzeichnisse, etc. Als Hinweis, die beste Praxis zu sein scheint, haben die Fass-Datei sein index.ts in einem Ordner, da der TypeScript compiler sucht nach der Datei, die als default, wenn Ihr einen Ordner importieren aus.
```
//without barrel files (hopefully they would be not randomly ordered to make it even harder...)
import { Class1 } from 'app/shared/module1/subpath1/subpath2/class1.service';
import { Class2 } from 'app/shared/module1/subpath1/class2.component';
import { Interface1 } from 'app/shared/module1/module1.model';
import { Class3} from 'app/shared/module2/subpath3/class3.service';
import { Interface2 } from 'app/shared/module2/module2.model';

//using barrel files
import { Class1, Class2, Interface1 } from 'app/shared/module1';
import { Class3, Interface2 } from 'app/shared/module2';
```
Con: Zusätzliche Datei

In der versucht, zu identifizieren, die Nachteile, die einzige Sache, die ich denken kann, ist, erstellen Sie eine andere Datei für jedes Modul (oder vielleicht auch sub-Ordner, je nachdem, wie Sie wollen, es zu tun). Es hat keine Laufzeit-oder compile-Zeit-Effekt so weit als ich bin bewusst, obwohl.
- Vielen Dank! Ich habe noch nie gegraben, tief genug, auf der offiziellen docs zu sehen, aber ich habe bemerkt etwas ähnliches, wenn wir importierten Module aus eckigen, obwohl ich war besorgt, weil ich es noch nie gesehen haben vor. Ok, du hast mich überzeugt, zumindest jetzt habe ich etwas, dass die Unterstützung der früheren fordern.
InformationsquelleAutor Daniel W Strimpel

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.