VIPER/MVP iOS项目中Core Location方法的放置位置咨询

Great question—this is such a common sticking point when bridging Apple's system frameworks to VIPER or MVP, especially since we’re all trying to keep presenters lean, testable, and decoupled from platform-specific code. Let’s break this down clearly:

Why You Shouldn’t Put Core Location Directly in the Presenter #

Presenters in VIPER/MVP are meant to handle business logic, not platform-specific interactions or system dependencies. Here’s why Core Location doesn’t belong here:

• Testability nightmare: CLLocationManager is tied to iOS’s system services. If your presenter directly instantiates or relies on it, you can’t easily mock location updates or permissions in unit tests—you’d have to rely on real system behavior, which is slow and unreliable for testing.
• Violates single responsibility: Presenters shouldn’t handle system-level UI like permission prompts or location error alerts. Those are strictly View layer concerns.
• Couples your presenter to iOS: If you ever wanted to reuse this presenter logic across platforms (like macOS or watchOS), you’d be stuck rewriting it because CLLocationManager is iOS-only.

Why Shoving Everything in ViewController Isn’t Ideal Either #

Dumping all Core Location code into your ViewController might seem like the easy fix, but it leads to:

• Massive "view controller bloat": Your VC will end up handling location updates, permission requests, UI rendering, and business logic—violating the single responsibility principle.
• Hard to reuse logic: If another screen needs location data, you’d have to duplicate code across VCs instead of reusing a centralized service.

The Optimal Solution: Abstract a Location Service Layer #

The sweet spot is to decouple Core Location from both the Presenter and ViewController using an abstraction layer. Here’s how it works:

Step 1: Define a Platform-Agnostic Protocol #

Create a protocol that defines the location functionality your app needs, without referencing CLLocationManager directly:

protocol LocationProviding {
    func requestCurrentLocation(completion: @escaping (Result<CLLocation, Error>) -> Void)
    func startContinuousLocationUpdates(_ updateHandler: @escaping (Result<CLLocation, Error>) -> Void)
    func stopContinuousUpdates()
}

Step 2: Implement the Protocol with Core Location #

Create a concrete class that wraps CLLocationManager and conforms to your protocol. This class lives in the View layer (or a shared services directory) since it’s tied to iOS:

class CoreLocationProvider: NSObject, LocationProviding, CLLocationManagerDelegate {
    private let manager = CLLocationManager()
    private var singleRequestCompletion: ((Result<CLLocation, Error>) -> Void)?
    private var continuousUpdateHandler: ((Result<CLLocation, Error>) -> Void)?

    override init() {
        super.init()
        manager.delegate = self
    }

    func requestCurrentLocation(completion: @escaping (Result<CLLocation, Error>) -> Void) {
        singleRequestCompletion = completion
        manager.requestWhenInUseAuthorization()
        manager.startUpdatingLocation()
    }

    func startContinuousLocationUpdates(_ updateHandler: @escaping (Result<CLLocation, Error>) -> Void) {
        continuousUpdateHandler = updateHandler
        manager.requestWhenInUseAuthorization()
        manager.startUpdatingLocation()
    }

    func stopContinuousUpdates() {
        manager.stopUpdatingLocation()
        continuousUpdateHandler = nil
    }

    // MARK: CLLocationManagerDelegate
    func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
        guard let latestLocation = locations.last else { return }
        
        // Handle single request
        if let completion = singleRequestCompletion {
            completion(.success(latestLocation))
            singleRequestCompletion = nil
            manager.stopUpdatingLocation()
        }
        
        // Handle continuous updates
        continuousUpdateHandler?(.success(latestLocation))
    }

    func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) {
        singleRequestCompletion?(.failure(error))
        continuousUpdateHandler?(.failure(error))
    }
}

Step 3: Connect ViewController, Service, and Presenter #

Your ViewController will hold an instance of LocationProviding, handle any system-specific UI (like explaining why permission is needed), and pass location data to the Presenter:

class LocationViewController: UIViewController {
    private let presenter: LocationPresenter
    private let locationProvider: LocationProviding

    // Inject dependencies for testability
    init(presenter: LocationPresenter, locationProvider: LocationProviding = CoreLocationProvider()) {
        self.presenter = presenter
        self.locationProvider = locationProvider
        super.init(nibName: nil, bundle: nil)
    }

    @IBAction func fetchLocationTapped(_ sender: UIButton) {
        locationProvider.requestCurrentLocation { [weak self] result in
            switch result {
            case .success(let location):
                self?.presenter.didReceiveLocation(location)
            case .failure(let error):
                self?.presenter.didFailToFetchLocation(error)
            }
        }
    }
}

Step 4: Keep Presenter Clean and Testable #

Your Presenter only depends on the LocationProviding protocol, not the iOS-specific implementation. This makes mocking trivial for unit tests:

class LocationPresenter {
    private weak var view: LocationViewProtocol?

    init(view: LocationViewProtocol) {
        self.view = view
    }

    func didReceiveLocation(_ location: CLLocation) {
        // Handle business logic: format coordinates, call APIs, filter data, etc.
        let formattedCoords = "Lat: \(String(format: "%.4f", location.coordinate.latitude)), Lon: \(String(format: "%.4f", location.coordinate.longitude))"
        view?.displayLocation(formattedCoords)
    }

    func didFailToFetchLocation(_ error: Error) {
        view?.displayError(message: error.localizedDescription)
    }
}

Step 5: Mock the Service for Testing #

Write a mock implementation of LocationProviding to test your Presenter without relying on real system location services:

class MockLocationProvider: LocationProviding {
    var mockLocation: CLLocation?
    var mockError: Error?

    func requestCurrentLocation(completion: @escaping (Result<CLLocation, Error>) -> Void) {
        if let location = mockLocation {
            completion(.success(location))
        } else if let error = mockError {
            completion(.failure(error))
        }
    }

    func startContinuousLocationUpdates(_ updateHandler: @escaping (Result<CLLocation, Error>) -> Void) {}
    func stopContinuousUpdates() {}
}

Final Takeaways #

• Presenter = Business Logic Only: Never tie your presenter to platform-specific APIs like CLLocationManager. Keep it focused on processing data and coordinating between the View and any data sources.
• ViewController = System Interaction: Let your VC handle permission prompts, system callbacks, and forwarding data to the presenter.
• Abstraction = Testability: Using protocols to wrap system frameworks keeps your code decoupled, reusable, and easy to test.

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