mwpowellhtx
commented
4 months ago Pretty much sorted out and resolved. We "root" a Bootstrapper instance in the Application Resources, and this is working out very nicely. Everything that needs to be configured, requested, resolved, messaged, focuses on that Bootstrapper instance.
Prefaced with the caveat, approaching the DI question, we "get it". The "composition root" is a sort of old school Castle Windsor based, IIRC, way of . Taking nothing away from that idea. But we think it can be done better "today".
As for Dependency Injection resolution, but also allowing a more effective communication when certain key events are taking place, i.e. selecting culture, for instance. We think it makes better sense to consider default implementations, but perhaps also allowing subscribers DI paths for default instances, especially considering not only catalogs but also localizers are being distributed in half a dozen other places. We especially want for the culture communication, involving the
ICatalog, or anICatalogContext(TBD) therein, to be such a natural substrate that we do not have to do too much in the way of overthinking any "roots" or "compositions".Off the cuff, we think that perhaps it is worthwhile adopting the CommunityToolkit.Mvvm dependency supporting this aspect. Will probably go this route, even though it is more of an implementation detail. In particular its ability to relay messages, i.e. culture selection, in a weak referenced manner, very low impact, high value.