2016-06-16 7 views
0

Derzeit habe ich alle Dienste innerhalb eines Dienste-Verzeichnis und mehrere Komponenten auf ihnen abhängig und auch ein Service hat die Abhängigkeit von einem anderen Dienst und so weiter. Das Abhängigkeitsdiagramm von Diensten und Komponenten würde verrückt aussehen. Aus diesem Grund bekomme ich in bestimmten Fällen beim Versuch, einen Dienst in einen anderen zu injizieren, einen DI-Fehler. Es folgt ein Beispiel eines meiner Situation:Empfohlene Architektur Dienstleistungen in Angular 2

import {stuff} from 'stuffs'; 

@Injectable() 
export class ApiService 
{ 
    getData(): Observable<string>{ 
     return this.http.get(url).map(v => v.json()); 
    } 
} 

@Injectable() 
export class SomeService 
{ 
    constructor(private apiService: ApiService){ 

    } 
} 

@Component() 
export class SomeComponent 
{ 
    constructor(private apiService: ApiService, 
     private someService: SomeService){ 

    } 
} 

ich keine empfohlene Muster Dienste fanden für die Organisation so nach viel Code geschrieben ich für einige Hinweise bin zu fragen, die mich auf richtige Richtung zeigen kann und Refactoring es.

+0

das ist nicht genug Informationen. Welche Art von DI-Fehler bekommen Sie? Ich habe einen Winkel 2 Anwendung, bei Dienstleistungen von anderen Dienste zu injizieren, aber wenn man den gefürchteten Diamanten der Vererbung schafft es brechen wird (es sei denn, sie schließlich, dass behoben haben, habe ich nicht RC1 noch aktualisiert) – kirinthos

+0

welchen Fehlern bekommen Sie? Das Szenario, das Sie hier zeigen, sollte funktionieren. Es ist besser, die vollständige Fehlermeldung in diesen Fällen zu posten, Sie erhalten effektivere Hilfe wie diese –

+0

@ AngularUniversity Ich bin nicht in der Lage, den Fehler im Moment zu reproduzieren. Aber kann ich zumindest einen Hinweis auf empfohlene Praktiken für die Organisation von Services in einer angular 2 App bekommen? – lbrahim

Antwort

3

Es ist ein Styling Guide auf Winkel 2 Website: https://angular.io/docs/ts/latest/guide/style-guide.html#!#application-structure

mit Dateinamen beschreibend sein kann und den Inhalt der Datei einer Komponente genau zu halten.

Vermeiden Sie Dateien mit mehreren Komponenten, mehrere Dienste oder eine Mischung.

Warum? Wir verbringen weniger Zeit mit Suchen und Picken nach Code und werden effizienter. Wenn das bedeutet, dass wir längere Dateinamen wollen, dann sei es so.

Aber auch auf dem kleinen Zettel steht:

Es gibt Abweichungen der 1 pro Datei Regel, wenn wir eine Reihe von sehr kleinen Features, die alle miteinander verbunden sind, wie sie sind immer noch leicht identifizierbar.

Es gibt auch eine Gesamt Ordner- und Dateistruktur Führung und vieles mehr, in dem Sie interessante Sachen finden könnten.

Und werfen Sie einen Blick auf diese Antwort für Dienstleistungen auf andere Dienstleistungen abhängig: https://stackoverflow.com/a/33979228/5706293

+0

Warum habe ich einen Downvote bekommen? – echonax

+0

Ich denke, weil es eine Link-only-Antwort ist, die entmutigt wird. Die Antwort sollte die relevanten Teile direkt enthalten. Sie können die relevanten Teile aus dem Style Guide direkt in Ihrer Antwort angeben. –

+1

@ GünterZöchbauer Oh, mach dann. Danke für den Tipp! – echonax