Services use standard interfaces to make shared resources available to multiple display components. The actual object providing the service may change for different use cases, just as long as each implementation complies with the rules defined by the interface.
For example: one implementation of a persistence service might save user data to local storage, while another might save the data on a remote server via a web service. Your app’s “main” class decides which service implementations are required based on the needs of the app.
Benefits of a service architecture
Services allow you to swap out the real implementation with fake or test services. Here is the tile again, all hooked up to streaming data, and sending trade messages to the server:
With a service architecture we can have workbenches. Here is the tile in the workbench with fake services that the tools on the left and right can control:
Productivity benefits of workbenches:
- You can develop the tile without the server components being ready
- Developing without having to connect to the server means less reliance on other parts of the system being up
- Not having to load the rest of the app means a simpler development environment
- You can test for edge cases without spending time getting other parts of the system having to respond with that data
Creating your own service is as trivial as creating an object, and registering it with the ServiceRegistry.