架構建議與資源

Separation of concerns is the most important architectural principle. The data layer exposes application data to the rest of the app, and contains most of the business logic in your application. The UI layer displays application data and listens for user events from users. The UI layer contains separate classes for UI logic and widgets.

The repository pattern is a software design pattern that isolates the data access logic from the rest of the application. It creates an abstraction layer between the application's business logic and the underlying data storage mechanisms (databases, APIs, file systems, etc.). In practice, this means creating Repository classes and Service classes.

Separation of concerns is the most important architectural principle. This particular separation makes your code much less error prone because your widgets remain "dumb".

The ChangeNotifier API is part of the Flutter SDK, and is a convenient way to have your widgets observe changes in your ViewModels.

There are many options to handle state-management, and ultimately the decision comes down to personal preference. Read about our ChangeNotifier recommendation or other popular options.

Logic should be encapsulated in methods on the ViewModel. The only logic a view should contain is:

• Simple if-statements to show and hide widgets based on a flag or nullable field in the ViewModel
• Animation logic that relies on the widget to calculate
• Layout logic based on device information, like screen size or orientation.
• Simple routing logic

A domain layer is only needed if your application has exceeding complex logic that crowds your ViewModels, or if you find yourself repeating logic in ViewModels. In very large apps, use-cases are useful, but in most apps they add unnecessary overhead.

Use in apps with complex logic requirements.

Data updates should only flow from the data layer to the UI layer. Interactions in the UI layer are sent to the data layer where they're processed.

Commands prevent rendering errors in your app, and standardize how the UI layer sends events to the data layer. Read about commands in the architecture case study.

Immutable data is crucial in ensuring that any necessary changes occur only in the proper place, usually the data or domain layer. Because immutable objects can't be modified after creation, you must create a new instance to reflect changes. This process prevents accidental updates in the UI layer and supports a clear, unidirectional data flow.

You can use packages to help generate useful functionality in your data models, freezed or built_value. These can generate common model methods like JSON ser/des, deep equality checking and copy methods. These code generation packages can add significant build time to your applications if you have a lot of models.

Using separate models adds verbosity, but prevents complexity in ViewModels and use-cases.

Use in large apps.

Dependency injection prevents your app from having globally accessible objects, which makes your code less error prone. We recommend you use the provider package to handle dependency injection.

Go_router is the preferred way to write 90% of Flutter applications. There are some specific use-cases that go_router doesn't solve, in which case you can use the Flutter Navigator API directly or try other packages found on pub.dev.

We recommend naming classes for the architectural component they represent. For example, you may have the following classes:

• HomeViewModel
• HomeScreen
• UserRepository
• ClientApiService

For clarity, we do not recommend using names that can be confused with objects from the Flutter SDK. For example, you should put your shared widgets in a directory called ui/core/, rather than a directory called /widgets.

Repository classes are the sources of truth for all data in your app, and facilitate communication with external APIs. Creating abstract repository classes allows you to create different implementations, which can be used for different app environments, such as "development" and "staging".

• Write unit tests for every service, repository and ViewModel class. These tests should test the logic of every method individually.
• Write widget tests for views. Testing routing and dependency injection are particularly important.

Fakes aren't concerned with the inner workings of any given method as much as they're concerned with inputs and outputs. If you have this in mind while writing application code, you're forced to write modular, lightweight functions and classes with well defined inputs and outputs.