Service Locator — bản chất của mẫu, registry trung tâm và DI

Service Locator là gì: bản chất và cấu trúc của mẫu

Service Locator là một mẫu tập trung hóa việc tạo và cung cấp dịch vụ. Nó dựa trên một lớp Singleton (Locator) chứa một Registry các dịch vụ: một từ điển nơi khóa là loại dịch vụ (hoặc định danh) và giá trị là triển khai cụ thể. Mã client gọi ServiceLocator.resolve(ServiceProtocol.self) và nhận một phiên bản sẵn sàng. Mẫu không quy định cách dịch vụ được tạo — factory, container DI hoặc new bên trong bộ định vị.

Cấu trúc của mẫu — Registry (từ điển loại [String: Any]), Locator (lớp tĩnh với register và resolve), Service (dịch vụ đang được đăng ký). Registry có thể lưu trữ các factory (closure/lambda để tạo đối tượng) hoặc các phiên bản sẵn sàng. Bộ định vị có thể là toàn cục (một cho mỗi ứng dụng) hoặc có phạm vi (theo tính năng/mô-đun). Giải quyết dịch vụ là tra cứu trong từ điển theo loại. Swift và Kotlin sử dụng loại làm khóa thông qua metatype: ObjectIdentifier(ServiceProtocol.self).

Lịch sử của mẫu — Service Locator được mô tả trong sách Java Patterns (1998) và sau đó trong Core J2EE Patterns (2001). Bài viết năm 2004 của Martin Fowler so sánh Service Locator với DI, lưu ý rằng Service Locator là một "giải pháp thay thế đơn giản hơn, nhưng tệ hơn cho kiểm thử." Trong phát triển di động, Service Locator đã được sử dụng trong các dự án Android đầu tiên và ứng dụng iOS trước khi Dagger và Swinject xuất hiện. Hiện nay, mẫu này thường được tìm thấy trong các dự án kế thừa và nguyên mẫu.

Service Locator trong Swift: registry dịch vụ toàn cục

Service Locator trong Swift — triển khai thông qua các thuộc tính tĩnh và từ điển an toàn luồng. Một registry với ObjectIdentifier(Protocol.self) làm khóa và factory (() -> Any) làm giá trị được sử dụng. Khởi tạo lười biếng (lazy var) là thực hành tiêu chuẩn: dịch vụ được tạo khi có yêu cầu đầu tiên. Swift yêu cầu ép kiểu tường minh trong quá trình resolve: guard let service = locator.resolve(ServiceProtocol.self) else { return }.

final class ServiceLocator {
    static let shared = ServiceLocator()
    private var registry: [ObjectIdentifier: Any] = [:]
    private let lock = NSLock()

    func register<T>(_ type: T.Type, factory: @escaping () -> T) {
        lock.lock()
        registry[ObjectIdentifier(type)] = factory
        lock.unlock()
    }

    func resolve<T>(_ type: T.Type) -> T {
        lock.lock()
        defer { lock.unlock() }
        guard let factory = registry[ObjectIdentifier(type)] as? () -> T else {
            fatalError("Service \(type) not registered")
        }
        return factory()
    }

    func reset() {
        lock.lock()
        registry.removeAll()
        lock.unlock()
    }
}

// Đăng ký
ServiceLocator.shared.register(NetworkServiceProtocol.self) { NetworkService() }

// Sử dụng
let network = ServiceLocator.shared.resolve(NetworkServiceProtocol.self)

Quản lý phạm vi — bộ định vị có thể lưu trữ factory (transient — đối tượng mới mỗi lần) hoặc phiên bản sẵn sàng (singleton). Đối với factory, một closure được đăng ký và gọi mỗi lần resolve. Đối với singleton, một closure ghi lại phiên bản đã tạo. Thêm phạm vi: .transient, .singleton, .weak (tham chiếu yếu — đối tượng tồn tại khi ai đó giữ tham chiếu). Phạm vi weak thuận tiện cho UIViewController của UIKit để tránh rò rỉ khi pop/dismiss.

Service Locator trong Kotlin: đăng ký lười biếng

Service Locator trong Kotlin — một triển khai nhỏ gọn thông qua object (Singleton) với các hàm inline reified cho an toàn kiểu. Kotlin cho phép một bộ định vị ngắn gọn: val service by locator() với một delegate, làm cho mã sạch hơn. Reified generics () thay thế ObjectIdentifier — kiểu được lấy từ generic. Các bộ định vị Kotlin thường sử dụng ConcurrentHashMap để an toàn luồng mà không cần khóa tường minh.

object ServiceLocator {
    private val registry = ConcurrentHashMap<Class<*>, () -> Any>()

    inline fun <reified T: Any> register(noinline factory: () -> T) {
        registry[T::class.java] = factory
    }

    @Suppress("UNCHECKED_CAST")
    inline fun <reified T: Any> resolve(): T {
        val factory = registry[T::class.java]
            ?: throw IllegalStateException("Service ${T::class.simpleName} not registered")
        return factory() as T
    }

    fun clear() {
        registry.clear()
    }
}

// Đăng ký
ServiceLocator.register<ApiService> { RetrofitApiService() }

// Sử dụng trong lớp
class UserRepository {
    private val api: ApiService = ServiceLocator.resolve()
    private val db: Database = ServiceLocator.resolve()
}

// Ủy quyền cho giải quyết lười biếng
class LocatorDelegate<reified T: Any> : Lazy<T> {
    override val value: T get() = ServiceLocator.<T>resolve()
    override fun isInitialized(): Boolean = true
}

inline fun <reified T: Any> locator(): Lazy<T> = LocatorDelegate()
// Sử dụng: val api by locator()

Service Locator trong Android — được tìm thấy trong các dự án cũ trước Dagger. Jetpack Hilt và Koin đã thay thế Service Locator trong cộng đồng Android. Tuy nhiên, bộ định vị vẫn phù hợp cho kiểm thử đơn vị: một ServiceLocator giả đơn giản với các dịch vụ mock không cần Hilt. Ưu điểm: không cần chờ biên dịch Dagger cho kiểm thử. Nhược điểm: nếu bạn quên ghi đè bộ định vị trong kiểm thử, các kiểm thử sẽ sử dụng dịch vụ sản xuất.

Service Locator vs DI: so sánh và khi nào chọn cái gì

Tính tường minh của phụ thuộc — sự khác biệt chính. DI khai báo phụ thuộc một cách tường minh: init(service: ServiceProtocol) — bất kỳ IDE nào cũng hiển thị phụ thuộc của lớp. Service Locator ẩn chúng: dependencies = ServiceLocator.resolve() — ẩn bên trong phương thức. Với DI, bạn có thể thấy ngay tất cả phụ thuộc của lớp; với Service Locator, bạn cần đọc toàn bộ thân lớp. Điều này làm cho mã Service Locator kém dự đoán hơn: thay đổi registry có thể phá vỡ bất kỳ lớp nào sử dụng bộ định vị.

Khi nào Service Locator được biện minh — nguyên mẫu và MVP (khởi đầu nhanh không cần cấu hình). Dự án kế thừa nơi không thể thêm framework DI (xây dựng phức tạp, hạn chế của linter). Thư viện công cụ (ghi log, báo cáo sự cố) — chúng đã là toàn cục. Đối với ứng dụng sản xuất với đội ngũ 3+ nhà phát triển, DI được khuyến nghị: phụ thuộc tường minh giảm số lỗi khi tái cấu trúc và đơn giản hóa việc giới thiệu nhà phát triển mới.

Vấn đề của Service Locator và các giải pháp thay thế

Phụ thuộc bị ẩn — một lớp sử dụng ServiceLocator.resolve() bên trong phương thức không thể được phân tích tĩnh. IDE không hiển thị phụ thuộc, trình biên dịch không kiểm tra dịch vụ đã được đăng ký chưa. Lỗi "Service not registered" chỉ xảy ra khi chạy. Tái cấu trúc trở nên nguy hiểm: xóa một dịch vụ khỏi registry có thể phá vỡ bất kỳ lớp nào trong ứng dụng. DI giải quyết vấn đề này thông qua kiểm tra lúc biên dịch (Dagger) hoặc hàm tạo tường minh.

Vấn đề kiểm thử — mỗi bài kiểm thử phải cấu hình ServiceLocator.shared với tất cả phụ thuộc. Sau kiểm thử — đặt lại trạng thái. Trong quá trình thực thi kiểm thử song song, trạng thái toàn cục của ServiceLocator.shared dẫn đến điều kiện tranh đua: một kiểm thử đăng ký mock, kiểm thử khác nhận mock của người khác. Giải pháp: bộ định vị có phạm vi (một cho mỗi kiểm thử) hoặc ThreadLocal. DI giải quyết vấn đề này ngay từ đầu: mỗi kiểm thử tạo phiên bản riêng với phụ thuộc mock.

// Vấn đề kiểm thử Service Locator
class LoginViewModelTests: XCTestCase {
    override func setUp() {
        super.setUp()
        // Thiết lập registry toàn cục cho kiểm thử
        ServiceLocator.shared.register(AuthServiceProtocol.self) { MockAuthService() }
    }

    override func tearDown() {
        ServiceLocator.shared.reset()
        super.tearDown()
    }

    func testLogin() {
        let viewModel = LoginViewModel() // sử dụng ServiceLocator nội bộ
        // kiểm thử...
    }
}

Giải pháp thay thế cho Service Locator — DI (Dagger, Swinject), Factory Method, Ambient Context. Factory Method — một mẫu đơn giản không có trạng thái toàn cục: một lớp factory tạo dịch vụ và được truyền qua hàm tạo. Ambient Context — một giải pháp thay thế an toàn luồng cho các mối quan tâm xuyên suốt (ghi log, ủy quyền). Giải pháp thay thế tốt nhất là Constructor Injection với factory thủ công không cần framework DI: tạo phụ thuộc tường minh trong factory với truyền qua hàm tạo mang lại sự rõ ràng của DI mà không cần độ phức tạp của việc cấu hình Dagger/Swinject.