基于静态JSON的Flutter List-List-Detail视图应用架构设计咨询

Hey there! Great question about architecting your List-List-Detail app with static JSON—let’s break this down into actionable, maintainable practices that’ll scale well even if you expand the app later.

Should You Create Separate Models for Each View? #

Short answer: No, create models for your data entities, not your views.

Here’s why: Your views (all lists overview, single list, single item detail) are just different ways to present parts of your data hierarchy. For example, if your JSON has three distinct levels:

1. A top-level list of categories (the "all lists" view)
2. A list of items under each category (the "single list" view)
3. Full details for a single item (the "detail" view)

You should create three model classes that map directly to these data entities—like Category, ListItem, and ItemDetail—not one per view. This way, you can reuse models across views: the Category model might be used in both the overview (to show category names/icons) and in the single list view (to display the category header).

Binding models to data instead of views keeps your code DRY and flexible—if you later add a new view that shows category previews, you don’t need to create a new model.

Where to Put JSON Loading & Parsing Logic? #

Don’t put loading/parsing inside your model classes. Models should be pure data containers—their only job is to hold structured data, not handle file I/O or serialization.

Instead, create a dedicated data service class (like JsonDataManager or StaticDataService) that handles all the heavy lifting:

• Reading static JSON files from your app’s assets/resources
• Parsing JSON into your model objects (use a serialization library like Swift’s Codable, Kotlin’s Gson, or JavaScript’s JSON.parse() to avoid manual parsing errors)
• Caching parsed data (since it’s static, you only need to load it once—store it in memory to speed up subsequent view loads)
• Handling errors (e.g., missing files, malformed JSON)

Example Workflow #

1. Your view (e.g., the all-lists overview) calls a method on the data service like getAllCategories().
2. The service checks if it already has cached categories—if yes, returns them immediately.
3. If not, it reads the categories.json file, parses it into a list of Category models, caches the result, and returns it to the view.
4. The view then uses the Category models to render its UI.

Quick Code Snippet (Kotlin Example) #

Model Classes

// Pure data models—no logic here
data class Category(val id: String, val name: String, val icon: String)
data class ListItem(val id: String, val title: String, val preview: String)
data class ItemDetail(val id: String, val title: String, val fullContent: String, val images: List<String>)

Data Service Class

class JsonDataService(private val context: Context) {
    private val gson = Gson()
    // Cache parsed data to avoid reloading files
    private var cachedCategories: List<Category>? = null

    fun getAllCategories(): Result<List<Category>> {
        cachedCategories?.let { return Result.success(it) }
        
        return try {
            // Read JSON file from assets
            val jsonString = context.assets.open("categories.json")
                .bufferedReader()
                .use { it.readText() }
            
            // Parse into model objects
            val categories = gson.fromJson(jsonString, Array<Category>::class.java).toList()
            cachedCategories = categories
            
            Result.success(categories)
        } catch (e: Exception) {
            // Handle errors (file not found, invalid JSON, etc.)
            Result.failure(e)
        }
    }

    // Similar methods for fetching items by category ID and item details
    fun getItemsForCategory(categoryId: String): Result<List<ListItem>> {
        // Logic to read items_{categoryId}.json, parse, cache, return
    }

    fun getItemDetail(itemId: String): Result<ItemDetail> {
        // Logic to read item_{itemId}.json, parse, cache, return
    }
}

Additional Best Practices #

• Error Handling: Always return success/failure states (like Kotlin’s Result type) instead of throwing exceptions directly in the service—this lets your views gracefully show error messages if something goes wrong.
• Immutability: Make your model classes immutable (use val in Kotlin, let in Swift, readonly in C#) to prevent accidental data modification.
• Consistent Naming: Name your JSON files to match your data hierarchy (e.g., categories.json, items_books.json, item_123.json) so it’s easy to find and load them.
• Reuse Parsing Logic: Leverage serialization libraries instead of writing manual JSON parsers—they reduce boilerplate and minimize human error.

Final Takeaway #

Structure your app around data entities (not views) and keep concerns separated:

• Models = pure data containers
• Data service = file loading + parsing + caching
• Views = display data from the service and handle user interactions

This architecture keeps your code clean, maintainable, and easy to update if you ever need to change your JSON structure or add new views.

内容的提问来源于stack exchange，提问作者labarna