iOS VIPER架构下内存数据管理及多屏分步创建实体方案咨询

Hey there! Let’s tackle your two VIPER-related questions—they’re both super practical scenarios that come up often when building iOS apps with this architecture.

1. Memory Data Storage & Passing in VIPER #

First, let’s clarify how data moves around and stays in memory in VIPER, since each component has a clear, single responsibility:

• Entities: These are your pure data models (usually structs or classes if you need reference semantics). They hold raw data with no business logic, and they’re the core data carriers across the architecture. In memory, they’re just regular objects/values that get passed between components as needed.
• Interactors: This is where most memory-resident data lives for business logic. Interactors manage data fetching (from APIs, local storage), caching, and processing. If you need to keep data in memory temporarily (like a list of items fetched from a network call), the Interactor holds onto it—since it’s responsible for the data’s lifecycle, it can release it when it’s no longer needed.
• Data Flow Between Components:
  • Interactor → Presenter: When an Interactor finishes processing data, it uses a protocol callback to pass the data to the Presenter. The Presenter then transforms this data into a format the View can display (like view models) and sends it over.
  • Router → Presenter: When navigating to a new screen, the Router initializes the target module’s Presenter and passes any necessary data (like an Entity or draft model) directly to it.
  • View → Presenter: The View only passes raw user input (text field content, button taps) to the Presenter—it never holds onto business data or Entities. This keeps the View lightweight and focused solely on UI.
  • Pro tip: Avoid letting Views hold references to Entities or complex data models. Keep the View "dumb"—all data management belongs to Presenters and Interactors.

2. Multi-Step Test Entity Creation in VIPER #

This is a classic scenario where you need to collect data across multiple screens before creating a final Entity. Here’s how to structure it properly within VIPER:

Core Idea: Use a Temporary Draft Model #

Since the final TestEntity isn’t created until the end, you’ll need a draft model to store partial data as the user progresses through each screen. This draft acts as the single source of truth for the entire flow.

Code Organization #

• Flow Coordinator (or Dedicated Router): Create a TestEntityCreationCoordinator to manage the entire multi-step flow. This coordinator handles navigation between screens, holds the draft model, and initializes each step’s VIPER components. Using a coordinator keeps navigation logic out of individual Presenters, which aligns with VIPER’s single-responsibility principle.
• Per-Screen VIPER Components:
  • View: Each screen’s View only handles UI for its specific input (e.g., first screen has title/description text fields, second has question inputs). It collects user input and sends it to its Presenter.
  • Presenter: Each step’s Presenter receives the current draft from the coordinator, updates the relevant fields with user input, and validates the input (e.g., ensuring the title isn’t empty). Once valid, it tells the coordinator to navigate to the next screen, passing the updated draft.
  • Interactor: For most steps, the Interactor’s role is light—maybe just input validation. Only in the final step does the Interactor take the complete draft, convert it to a TestEntity, and handle persistence (Core Data, API call, etc.).
  • Router: The coordinator acts as the router for the flow, handling push/pop transitions between screens.

Where to Store the Flow’s Data #

• The Draft Model: Create a lightweight struct to hold partial data:

  struct TestEntityDraft {
      var title: String?
      var description: String?
      var questions: [Question]?
      var helperText: String?
  }
  

  The TestEntityCreationCoordinator holds onto this draft. When navigating to a new screen, it passes the draft to the target Presenter. When the user finishes input on that screen, the Presenter updates the draft and sends it back to the coordinator.
• Avoid Singletons: Resist the urge to use a singleton to store the draft—singletons have a global lifecycle, which can lead to memory leaks or leftover data if the user cancels the flow. The coordinator’s lifecycle is tied to the flow, so when the flow ends (whether completed or canceled), the coordinator and draft are released automatically.
• Final Entity Persistence: In the last step, the Presenter sends the complete draft to the Interactor. The Interactor validates all fields are present, converts the draft to a full TestEntity, and saves it to your data source. Once saved, the Interactor notifies the Presenter, which tells the View to show a success message, and the coordinator dismisses the flow.

Example Flow Walkthrough #

1. User taps "Create Test Entity" → TestEntityCreationCoordinator initializes with an empty TestEntityDraft and pushes the first screen (title/description input).
2. User enters title/description → View sends input to Presenter → Presenter updates the draft’s title/description → Presenter tells coordinator to push the question screen, passing the updated draft.
3. User adds questions → Presenter updates draft’s questions → coordinator pushes the helper text screen.
4. User enters helper text → Presenter updates draft’s helperText → coordinator pushes the final confirmation screen.
5. User taps "Create" → Presenter sends complete draft to Interactor → Interactor creates TestEntity and saves it → Interactor notifies Presenter of success → View shows success alert → coordinator pops all screens back to the start.

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