在不使用框架的php应用中，控制器应按业务页面或api资源组织，而非简单对应数据库表；地址类数据（如国家、城市）宜归入统一地址管理，避免为每张表创建独立控制器。
设计清晰的控制器结构是构建可维护PHP应用的关键一步。许多初学者容易陷入“一张表一个控制器”的误区，例如为 countries、cities、districts 各自创建 CountriesController、CitiesController 等——这看似直观，实则混淆了数据持久层与应用表现层的关注点。
控制器属于UI/交互层（即请求响应逻辑），其职责是协调用户意图（如“查看某人的完整档案”或“编辑收货地址”）与后端服务，而非映射数据库结构。因此，决策依据应是路由语义和用户场景，而非表数量：
-
✅ 若是面向前端的 Web 页面型应用（如后台管理系统），控制器应围绕“页面功能”组织：
- PersonProfileController：处理人员详情页（含关联的地区、城市、所属区域等展示）
- AddressManagementController：统一管理国家、省份、城市、区县的查询（只读）与地址簿增删改
- RegionSettingsController：仅在需要维护区域层级配置时启用（如管理员调整行政区划）
-
✅ 若是 RESTful API，则按资源（Resource）聚合设计：
立即学习“PHP免费学习笔记（深入）”；
// 示例：地址相关资源统一由 AddressResource 处理 class AddressResource { public function getCountries() { /* ... */ } public function getCitiesByCountry($countryId) { /* ... */ } public function getDistrictsByCity($cityId) { /* ... */ } }
⚠️ 注意事项：
- *避免 `Controller后缀**：PHP 5.3+ 支持命名空间，应使用语义化类名 + 命名空间分组，例如App\Http\Controllers\Person\ProfileController，而非PersonProfileController；类名本身应表达行为（如ProfileHandler、AddressResolver`）。
- 地址类数据通常为静态/低频变更：国家、城市等表更适合预加载为缓存数组或枚举，而非每次走完整MVC流程；可在服务层（如 AddressService）封装层级查询逻辑，控制器仅调用 $addressService->getFullLocation($personId)。
- 拒绝跨表方法污染单一职责：PersonController::getCityByPersonId() 是反模式——它将地址逻辑耦合进人员控制器，违背单一职责原则；正确做法是让 PersonController 调用 AddressService 获取所需地理信息。
总结：控制器是用户旅程的协调者，不是数据库的代理。从 URL 路由出发（如 /person/123, /api/addresses/countries），定义边界清晰、高内聚的控制器单元，并通过服务层解耦数据获取逻辑——这才是无框架PHP项目长期可维护的核心实践。
