Manager use case

[elhe26]

Could you please provide a simple use case on how to use the manager part of this architecture?

Here's how I understand it:

1. We declare separate services (auth, storage, etc...).
2. Each viewmodel will have access to one service (since they won't know other viewmodels).
3. If a viewmodel needs more than one service, we use the manager to handle those services (since the manager is pointing to the individual services).

Regards,

[FilledStacks]

@elhe26 Not exactly. ViewModels can use as many services as you'd like them to use. A manager is a service that require other services to perform it's task. Something like the service that manages your information requested from your api.

It would require the caching service, application_api, database_service and most likely user_service to get user information for the requests. This would then be called a InformationManager, or PostsManager, or whatever the thing is that it's managing.

Like mentioned in the readme. There is no specific functionality purpose for a "Manager" it exists only to indicate that it's a service that is dependent on other services. It's a naming suggestion.

[FilledStacks]

https://github.com/FilledStacks/fs_architecture_v2_proposal/blob/master/lib/manager/authentication_manager.dart

[elhe26]

@FilledStacks oh. I think I understand now. We have a service to authenticate a user (auth_service) and we have a service to give a user access to some other service (storage, etc..). A manager will have these services (like the file on the link) and give the user access to the auth data to accomplish other tasks of the other service.

Is this right?

[FilledStacks]

Yes, just to make sure there's no confusion. A manager has no intended functional place in the architecture. It's ONLY there to distinguish between a service that requires other services and a service that doesn't. A service that requires no other services is called a service. A service that requires 1 or more services to do it's job is called a manager when being named, but it's still a service.

It's marked as a suggestion in the readme so if it's confusing then you should ignore it for now and just call it a service as well. It's purely for naming and making it easy to know when a service has dependencies.

[elhe26]

Roger that!