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...
Programmierer aus Leidenschaft. Ich lege besonders Wert auf Clean Code und liebe es mich durch legacy Code zu wühlen... und den dann zu refaktorieren 😉.
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.
Aus welchem Grund gibt es eigentlich überhaupt ein Core-Module?
In dem anderen Artikel über Clean Architecture mit Angular wurde ebenfalls ein leeres Core-Module angelegt:
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".
Auch wenn das Providers-Array nicht mehr vom Angular Team empfohlen wird, sehe ich in diesem Fall keinen Weg komplett daran vorbei zu kommen. Schließlich muss diese Definition:
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?
Programmierer aus Leidenschaft. Ich lege besonders Wert auf Clean Code und liebe es mich durch legacy Code zu wühlen... und den dann zu refaktorieren 😉.
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/...
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.