Im letzten Teil des Beitrags haben wir die Business Logik unseres Aufgaben Tools programmiert. In diesem Teil geht es darum, unsere Anwendung zum L...
For further actions, you may consider blocking this person and/or reporting abuse
Das ist ein wirklich schöner Artikel. Habe etwas lernen können!
Doch eine Sache verstehe ich nicht.
Wofür brauchen wir die Provider im Core-Modul?
@NgModule({
// ...
providers: [
AddToDoUseCase,
DeleteToDoUseCase,
EditToDoUseCase,
ShowToDoListUseCase,
]
})
export class CoreModule {
}
Das ginge doch auch ohne die Use-Cases. Die werden doch ohnehin durch "provideIn="root" zur Verfügung gestellt. Es sollte also auch ohne das funktionieren...
Danke für das Lob und den Hinweis 🙂 Ich dachte immer man müsste die immer im Modul registrieren aber tatsächlich reicht das providedIn schon aus, danke! Ich update den Code und den Artikel.
Super!
Was mich auch noch interessieren würde:
medium.com/intive-developers/appro...
Doch den Grund verstehe ich nicht. Es müsste doch gerade gewollt sein das Core-Module nicht zu haben, damit so wenig Framework wie möglich den Core "verschmutzt".
providers: [
{provide: ShowToDoListPresenter, useClass: TodoListPresenter}
]
z.B. wirklich in das PresentationModule (und nicht direkt per provideIn in den ShowToDoListPresenter), weil dort keine konkrete Referenz hingehört. Verstehe ich das richtig?
Das sehe ich vollkommen genau so wie du. Deswegen hab ich gestern das Core-Module auch schon rausgeworfen.
Ich hatte es ursprünglich so, wie ich es auch in Teil 1 geschrieben habe, dass ich die Services manuell verdrahtet habe. Das geschah im Core Module. Dadurch, dass die UseCases aber im Nachhinein eh mit
@Injectable({providedIn: 'root'})dekoriert sind, ist das Modul natürlich überflüssig. Ich hab das gestern schon im Code und im Post angepasst :-)Zu dem verdrahten der Presentern ist mir leider noch kein schöner Weg eingefallen
okay - dann ist alles klar. Ich war nur so verwirrt, weil ich diese Art von Implementierung zwei Mal gefunden habe. Einmal hier und noch mal in dem englischen Artikel. Zwei Mal ein Core Modul... aber hatte wohl in beiden Fällen den gleichen Ursprung.
Noch eine andere Frage: Die Komponenten greifen bei dir direkt auf einen konkreten UseCase zu (es gibt keine abstrakten Klassen dafür (i.e. "interfaces" bei clean architecture))
D.h., dass deine Komponente (das wäre der "Controller") direkt auf die Use cases zugreift ohne Interface dazwischen, wie in dem Buch. War das Absicht oder einfach Pragmatismus? (Siehe Foto aus dem Buch "Clean Architecture") Foto: dev-to-uploads.s3.amazonaws.com/i/...
Zwei richtig gute Beiträge! Für mich als „Angular Newbie“ sehr verständlich zu lesen.