Product Decisions This Supports
- Framework selection for new services: this package is the hinge point in the "webman vs. Laravel vs. ThinkPHP" decision. If your team's muscle memory is ThinkPHP's Active Record API and you want webman's resident-process performance, this adapter is what makes that combination viable without a rewrite. It is an enabler of the framework choice, not a feature in itself.
- Migration roadmap (ThinkPHP → webman): supports a phased migration where controllers and services keep
Db::name(...)->where(...)->select() style code while the runtime underneath changes. For a PM, that is the difference between a 6-month parallel-run migration and a 2-quarter full rewrite.
- Build vs. buy on persistence plumbing: the alternative is writing and maintaining your own connection-pool-aware ORM bootstrap for a long-running PHP process. That is undifferentiated work with a nasty failure mode (connection leaks, stale state across requests). Buy — it's ~a few hundred lines of glue you should never own.
- Use cases it unlocks: admin/back-office services, internal APIs, and mid-traffic CRUD products where query expressiveness needs are ordinary (joins, pagination, relations, transactions) and throughput matters more than domain-model purity.
- Roadmap constraint it imposes: choosing ThinkORM means any future "adopt Eloquent/Doctrine-style repositories" initiative becomes a data-layer migration. Flag that explicitly in your architecture roadmap so it isn't discovered later.
- Not a differentiator. With a low opportunity score and negligible dependent count, treat this as infrastructure hygiene. Do not build a product narrative or a hiring plan around it; do budget a half-day spike and a documented fallback.
When to Consider This Package
Adopt when all of the following hold:
- You are on webman (Workerman-based, resident process). This is not a Laravel package and does not belong in a Laravel, Symfony, or vanilla PHP-FPM app — it is an integration layer, not a general-purpose ORM.
- Your team already knows ThinkPHP's query builder / Active Record style, or you are migrating an existing ThinkPHP codebase.
- Your data access is conventional SQL (MySQL/PostgreSQL) with no heavy need for domain-mapping, unit-of-work, or identity-map semantics.
- You want connection pooling and coroutine/worker-safe connection handling without hand-rolling it.
- You are comfortable with a thin, low-star, low-adoption dependency — because it ships from the
webman-php org, treat it as effectively first-party glue rather than an independent vendor bet.
Look elsewhere when:
- You are not on webman. The entire value proposition disappears; use Eloquent (Laravel), Doctrine (Symfony), or plain PDO.
- You need a large ecosystem: migrations tooling, seeders, model factories, profiling integrations, IDE helpers, Stack Overflow answers. ThinkORM's ecosystem is real but ThinkPHP-shaped and much smaller than Eloquent's.
- Risk tolerance is low and the service is long-lived. Nine stars and zero recorded dependents is a genuine bus-factor and abandonment signal, regardless of the org it lives under. Mitigate with a pinned version and a written exit plan (a repository interface you can reimplement against PDO) before committing.
- You need advanced persistence: multi-database sharding, read/write splitting with sophisticated routing, event sourcing, or first-class NoSQL abstractions.
- You need transactions spanning concurrent coroutine work — validate this specifically in a spike; connection-pool semantics under concurrency are exactly where thin adapters bite.
Practical gate: run a one-day spike covering pooled connections under load, nested transactions, and a rollback-on-exception path. If it passes, adopt with a pinned version.
How to Pitch It (Stakeholders)
To executives (one paragraph): We can run our next service on webman's high-throughput runtime while keeping the database code our engineers already know, instead of paying for a rewrite or accepting a slower stack. The integration is a small, MIT-licensed piece of glue published under the framework's own organization, so it carries no license cost and no vendor lock-in — the data layer remains ordinary SQL we could reimplement if we ever needed to. Recommendation: adopt for services that fit our existing ThinkPHP skill base, budget one engineering day to validate it, and treat it as plumbing rather than a strategic bet.
To engineering leadership: This is a ~one-file adapter that connects ThinkORM to webman's connection pool and worker lifecycle. It removes the need for us to own pool management, stale-connection handling, and worker-restart edge cases. The trade-off is ecosystem size and adoption risk: nine stars, zero recorded dependents, and a maintainer set that overlaps with the webman core team. That is acceptable for glue code if we (a) pin the version, (b) keep data access behind repository interfaces, and (c) assign an owner who watches upstream releases. It is not acceptable as the foundation of a system-of-record data layer without that isolation.
Ask: approve a one-day spike and a pinned adoption for the next webman service; defer any broader ORM standardization decision until we have production telemetry from it.