`core.service.ServiceFactory` API uncertainties

[dfenerski]

Hello,

I write here because I could think of no better place to ask about something I find very interesting.

First, let me give some context - its about the "Service Factory" pattern, for which I recently saw a twitter post & a beautiful TS usage guide. I've included it as link below, as well as links to the relevant UI5 classes ( & method )

• https://btp.udina.de/development/ux/ui5-design-patterns.html#service-factory
• https://github.com/SAP/openui5/blob/master/src/sap.ui.core/src/sap/ui/core/service/Service.js
• https://github.com/SAP/openui5/blob/master/src/sap.ui.core/src/sap/ui/core/service/ServiceFactory.js
• https://github.com/SAP/openui5/blob/master/src/sap.ui.core/src/sap/ui/core/service/ServiceFactoryRegistry.js
• https://github.com/SAP/openui5/blob/ffc2b361dc08a4122626525ecbd058f6a9efa838/src/sap.ui.core/src/sap/ui/core/Component.js#L1180

Reading all of this was both surprising to me - I never knew about the existence of "service reuse" functionality in UI5 - and also very interesting - other frameworks may require 3rd party dependency management solutions but here, the API is built in, although its private.

Given those infos, I immediately started to think about the value of implementing this. As something native for the framework, it is "better" than developing a custom logic replacement. However I don't see how it may cover a couple of crucial use cases for us on which some light could be shed, namely:

1. Library support? All services have to be registered in the manifest.json, so this means even the library ones? The ones meant for greatest reuse? Now apps have to concern themselves with exactly what spec of services they have to pull & from where
2. Usage during custom control develpment? Given I have some custom control, lets say my.ns.Chart, I find it convenient to reuse some services, e.g a FormattingService for consistent currency formatting throughout the app. However the only way to "grab" services is through Component.getComponentById(...).getService(...), meaning the custom control has to grab a reference to the component -> coupling.
3. After transpilation, those classes are not real classes. Meaning we have to extend from BaseObject & therefore some functionalities are out of reach - e.g using method decorators (recently I've been slapping @Memo() on couple of methods for auto-memoization)
4. API Support? Given this has existed for some time now, it shows there is a use case for it. So is it safe to presume it won't get deleted in V2/V3? API Changes are fine by me, but should one go for it, it at least has to remain existent :)
5. Philosophical issues - This looks to me like some form of inversion of control. Consumers don't bother themselves with instantiating services, factories handle this. However isn't this some form of the "Service Locator" pattern then, where the Component acts as the main registry? If yes then it suffers from the same drawbacks - the Component is a "god object" which now has the responsibility to know everything. Additionally there's tight coupling in both the manifest (I have to say which services there are) & in the registration place (I have to register all my services manually)

I don't know if this qualifies as an "issue", but "discussions" are disabled so I didn't know where else to post.

I'd be very happy to discuss this somewhere.

Thanks & BR

Dimitar

[flovogt]

@petermuessig @codeworrior Your feedback is highly appreciated.🥳