-
Notifications
You must be signed in to change notification settings - Fork 441
Services
Dani Donisa edited this page Jul 20, 2023
·
6 revisions
You have a complex set of operations that need to be executed in a sequence synchronously or asynchronously.
Concentrate the core logic of a request operation into a service class which resides under src/api/app/services.
Services can easily become a code smell if not handled properly. If you find yourself with a service that has too many methods and/or becomes generally unreadable and hard to understand, you might have to find a bounded context or use one of the design patterns mentioned in that article.
- Each service should do only one thing.
- Name a service after what they do: if a service creates event subscriptions, then
EventSubscriptionCreator
would be a good name. - The main entry point for a service is the
call
method, with no parameters. All parameters should come via the constructor.
Links:
- Development Environment Overview
- Development Environment Tips & Tricks
- Spec-Tips
- Code Style
- Rubocop
- Testing with VCR
- Authentication
- Authorization
- Autocomplete
- BS Requests
- Events
- ProjectLog
- Notifications
- Feature Toggles
- Build Results
- Attrib classes
- Flags
- The BackendPackage Cache
- Maintenance classes
- Cloud uploader
- Delayed Jobs
- Staging Workflow
- StatusHistory
- OBS API
- Owner Search
- Search
- Links
- Distributions
- Repository
- Data Migrations
- next_rails
- Ruby Update
- Rails Profiling
- Installing a local LDAP-server
- Remote Pairing Setup Guide
- Factory Dashboard
- osc
- Setup an OBS Development Environment on macOS
- Run OpenQA smoketest locally
- Responsive Guidelines
- Importing database dumps
- Problem Statement & Solution
- Kickoff New Stuff
- New Swagger API doc
- Documentation and Communication
- GitHub Actions
- How to Introduce Software Design Patterns
- Query Objects
- Services
- View Components
- RFC: Core Components
- RFC: Decorator Pattern
- RFC: Backend models