A maintainable GetX project structure
GetX combines state, dependency registration, and routing, but these capabilities do not have to be adopted together. A maintainable GetX app keeps registration visible, limits controller lifetime, and lets repositories hide external services.
How the pieces connect
A starting folder structure
lib/
app/routes/
features/home/
bindings/home_binding.dart
controllers/counter_controller.dart
views/home_page.dart
domain/repositories/
data/repositories/Use route bindings for route-owned dependencies
A binding can register a controller when a route is opened. Treat a registration as an ownership decision: a checkout controller usually should not live for the entire application. Reserve permanent registrations for application services. Verify lifecycle behavior when using nested navigation or retaining tabs.
Keep views reactive and controllers focused
Use Obx around the smallest meaningful region that reads reactive state. A controller should coordinate one feature, not store every application value. Cancel subscriptions and timers when the controller is disposed. Avoid embedding HTTP requests in build methods.
Keep dependency lookup at a boundary
Global lookups are convenient but obscure requirements in tests. Pass repositories through constructors so the controller can be constructed with a fake. The binding or composition root can perform Get.find while domain logic stays independent of GetX.
Know when to choose another structure
GetX can be convenient for a small team already familiar with its conventions. For a large codebase with strict dependency visibility, explicit constructor composition or a provider graph may be easier to audit. You can use GetX routing with a different state solution; routing should not force a state migration.
Try this configuration
Feature First · GetX · GetX DI · GetX Routing
The generator includes a working counter example with a repository contract, selected dependencies, navigation, and local setup instructions. Extend the example around your own domain before shipping.
Configure your Flutter project →Continue reading
- A practical guide to Flutter Clean Architecture
- BLoC vs Riverpod: choose by how your team works
- Structure a Flutter Riverpod application
Primary references
Flutter application architecture documentation explains architectural recommendations. For state APIs, consult Riverpod documentation and BLoC documentation.