第235章　MVC架构与ICAI

235.1 MVC定义

MVC（Model-View-Controller）是一种应用程序分层架构模式，用于将数据与领域对象、用户界面以及请求控制过程进行职责分离。

MVC由三个基本部分组成：

Model：模型层，负责数据与领域对象；
View：视图层，负责数据展示；
Controller：控制器层，负责接收请求、组织应用流程并返回结果。

MVC的核心不是简单地把PHP文件分成三个目录，而是建立明确的职责边界：

$MVC=(M,V,C)MVC=(M,V,C)$

其中：

$MM$ ：Model，模型；
$VV$ ：View，视图；
$CC$ ：Controller，控制器。

基本请求流程为：

$Request→Controller→Model→Controller→View→ResponseRequest \rightarrow Controller \rightarrow Model \rightarrow Controller \rightarrow View \rightarrow Response$

但是，对于ICAI系统，仅使用传统的“Controller → Model → View”结构是不够的。

ICAI已经建立了Domain Object、Engine、Service、Repository、Persistence等多个工程层，因此MVC需要作为应用层组织方式嵌入ICAI，而不能替代ICAI本身的认知计算结构。

因此，ICAI中的MVC应定义为：

MVC是ICAI应用系统的请求处理与结果展示架构，而不是ICAI的认知模型本身。

ICAI负责回答：

系统如何表示个体、对象、状态、关系、知识、目标、能力、方法、决策、行为、反馈、记忆、经验、学习以及维护过程。

MVC负责回答：

用户请求如何进入系统、由谁组织处理、结果如何返回以及如何展示。

二者属于不同层次。

235.2 MVC职责

235.2.1 Controller职责

Controller（控制器）负责接收外部请求并启动应用流程。

Controller主要负责：

接收HTTP Request；
获取请求参数；
基本参数检查；
创建或调用Service；
将请求转换为应用服务调用；
接收Service结果；
决定返回View、JSON或其他Response；
处理页面级流程控制。

Controller不应该承担核心认知计算。

例如用户提交：

“检查某个对象当前是否存在异常。”

Controller不应该直接执行风险计算、异常判断、诊断计算和修复计算。

正确流程应该是：

$Request→Controller→MaintenanceService→DetectionEngine→DiagnosisEngine→ResultRequest \rightarrow Controller \rightarrow MaintenanceService \rightarrow DetectionEngine \rightarrow DiagnosisEngine \rightarrow Result$

Controller只负责启动这个过程。

因此：

$Controller≠EngineController\neq Engine$

同时：

$Controller≠Domain ObjectController\neq Domain\ Object$

也就是说，Controller不能代替认知对象，也不能代替计算引擎。

235.2.2 Model职责

在传统MVC中，Model通常被理解为数据模型。

在ICAI系统中，Model需要进一步区分为两个概念：

Domain Model；
Persistence Model。

Domain Model表示ICAI中的真实工程对象，例如：

Individual；
Object；
State；
Relation；
Knowledge；
Need；
Goal；
Capability；
Method；
Decision；
Behavior；
Action；
Result；
Feedback；
Memory；
Experience；
Risk；
Conflict；
Abnormality；
Diagnosis；
Protection；
Repair；
Learning。

Persistence Model则表示这些对象在数据库中的持久化结构。

因此：

$Domain Object≠Database RowDomain\ Object\neq Database\ Row$

二者之间通过Mapper进行转换：

$Domain Object→Mapper→Persistence Object→Repository→MySQLDomain\ Object \rightarrow Mapper \rightarrow Persistence\ Object \rightarrow Repository \rightarrow MySQL$

Model层因此不能简单等同于“数据库表”。

ICAI中的Model首先应该表达系统对象与领域结构，其次才是数据持久化。

235.2.3 View职责

View（视图）负责展示已经计算完成的数据。

View可以是：

HTML页面；
Smarty模板；
JSON输出；
后台管理页面；
表格；
状态页面；
诊断结果页面；
系统运行结果页面。

View只负责展示，不负责核心认知计算。

例如：

检测结果：异常
异常类型：状态异常
严重程度：3
诊断状态：待确认

这些数据应该由Controller从Service获取后传给View。

View不应该自己计算：

RiskScore
DiagnosisScore
CapabilityScore
DecisionScore

否则会造成展示层与认知层耦合。

因此：

$View≠EngineView\neq Engine$

并且：

$View≠ServiceView\neq Service$

235.3 ICAI与MVC

ICAI与MVC不是同一种概念。

MVC属于软件架构组织模式。

ICAI属于认知计算与工程系统体系。

二者的关系可以表示为：

$ICAI Cognitive Architecture+MVC Application Architecture→ICAI Application SystemICAI\ Cognitive\ Architecture + MVC\ Application\ Architecture \rightarrow ICAI\ Application\ System$

ICAI负责认知过程。

MVC负责应用入口、流程组织和结果展示。

因此不能把：

MVC

直接定义成：

ICAI认知架构

也不能把：

Model

直接等同于：

ICAI全部认知对象

更不能把：

Controller

定义成：

CognitiveEngine

正确的关系是：

$MVC⊃Application OrganizationMVC \supset Application\ Organization$

而：

$ICAI⊃Cognitive DomainICAI \supset Cognitive\ Domain$

两者在Service层和应用流程层连接。

235.3.1 MVC与ICAI核心对象对应关系

ICAI对象并不是全部放入Model文件夹后就结束。

应该按照职责进一步划分：

ICAI对象	主要工程位置
Individual	Domain Model
Object	Domain Model
State	Domain Model
Relation	Domain Model
Scene	Domain Model
Knowledge	Domain Model
Need	Domain Model
Goal	Domain Model
Capability	Domain Model
Method	Domain Model
Decision	Domain Model
Behavior	Domain Model
Action	Domain Model
Result	Domain Model
Feedback	Domain Model
Memory	Domain Model
Experience	Domain Model
Risk	Domain Model
Conflict	Domain Model
Abnormality	Domain Model
Diagnosis	Domain Model
Protection	Domain Model
Repair	Domain Model
Learning	Domain Model
各类计算	Engine
应用流程	Service
数据保存	Repository
页面展示	View
请求入口	Controller

因此，ICAI的工程结构不是：

Controller
Model
View

三个目录就完成。

而是：

Controller
    ↓
Service
    ↓
Domain Model
    ↓
Engine
    ↓
Repository
    ↓
Persistence
    ↓
MySQL

再由结果返回：

MySQL
    ↓
Repository
    ↓
Domain Model
    ↓
Service
    ↓
Controller
    ↓
View
    ↓
Response

235.4 系统分层

ICAI系统需要建立更加明确的分层结构。

建议采用以下工程结构：

ICAI Application
│
├── Controller
│
├── Service
│
├── Domain
│   ├── Individual
│   ├── Object
│   ├── State
│   ├── Relation
│   ├── Scene
│   ├── Knowledge
│   ├── Goal
│   ├── Capability
│   ├── Method
│   ├── Decision
│   ├── Behavior
│   ├── Action
│   ├── Result
│   ├── Feedback
│   ├── Memory
│   ├── Experience
│   ├── Risk
│   ├── Conflict
│   ├── Abnormality
│   ├── Diagnosis
│   ├── Protection
│   ├── Repair
│   └── Learning
│
├── Engine
│
├── Repository
│
├── Mapper
│
├── Persistence
│
└── View

这个结构体现的是：

$请求层→应用层→领域层→计算层→持久化层→数据库请求层 \rightarrow 应用层 \rightarrow 领域层 \rightarrow 计算层 \rightarrow 持久化层 \rightarrow 数据库$

235.4.1 Controller层

Controller是系统入口。

例如：

class CognitiveController
{
    protected $service;

    public function __construct($service)
    {
        $this->service = $service;
    }

    public function process($request)
    {
        return $this->service->process($request);
    }
}

Controller不直接操作数据库，也不直接执行复杂计算。

错误方式：

$pdo->query(...);

或者：

$riskScore = $probability * $impact;

如果这些逻辑直接写入Controller，就会导致应用入口承担持久化和认知计算职责。

正确方式是：

Controller
→ Service
→ Engine / Domain / Repository

235.4.2 Service层

Service是MVC与ICAI领域体系之间的重要连接层。

Service负责应用流程编排。

例如：

MaintenanceService

可以组织：

Detection
→ Risk / Conflict / Abnormality
→ Diagnosis
→ Protection / Repair
→ Execution
→ Result
→ Feedback
→ Verification

Service本身不应该重新实现Engine的计算规则。

因此：

$Service=OrchestrationService=Orchestration$

而：

$Engine=CalculationEngine=Calculation$

例如：

class DiagnosisRepairService
{
    protected $diagnosisEngine;
    protected $repairEngine;

    public function process($abnormality)
    {
        $diagnosis = $this->diagnosisEngine->diagnose($abnormality);

        if (!$diagnosis->isRepairable()) {
            return $diagnosis;
        }

        return $this->repairEngine->repair($diagnosis);
    }
}

这里Service负责流程组织。

DiagnosisEngine负责诊断计算。

RepairEngine负责修复计算。

235.4.3 Domain层

Domain（领域层）保存ICAI系统的核心对象定义。

例如：

class Goal
{
    protected $code;
    protected $name;
    protected $condition;
    protected $priority;
    protected $state;
}

Domain Object本身描述：

系统中的对象是什么。

而Engine描述：

如何对对象进行计算。

因此：

$Domain Object≠EngineDomain\ Object\neq Engine$

例如：

Goal

是目标对象。

GoalEngine

是目标相关计算组件。

235.4.4 Engine层

Engine是ICAI计算核心。

前面章节已经定义：

$Engine=(I,R,C,D,O)Engine=(I,R,C,D,O)$

其中：

$II$ ：Input，输入；
$RR$ ：Rule，规则；
$CC$ ：Condition，条件；
$DD$ ：Calculation，计算；
$OO$ ：Output，输出。

Engine负责确定性计算。

例如：

RiskEngine
ConflictEngine
DetectionEngine
DiagnosisEngine
DecisionEngine
MethodEngine
LearningEngine
UpdateEngine
CognitiveEngine
SelfMaintenanceEngine

这些Engine不是MVC的Controller，也不是View。

它们属于ICAI领域计算层。

235.4.5 Repository层

Repository负责领域对象与数据库之间的持久化边界。

例如：

Diagnosis
↓
DiagnosisMapper
↓
DiagnosisRepository
↓
PDO
↓
MySQL

Repository负责：

Load；
Save；
Update；
Delete；
Query；
Exists；
Mapping。

Repository不负责认知计算。

因此：

$Repository≠EngineRepository\neq Engine$

例如：

class DiagnosisRepository
{
    protected $pdo;

    public function __construct($pdo)
    {
        $this->pdo = $pdo;
    }

    public function findByCode($code)
    {
        // 从数据库读取Diagnosis持久化数据
    }

    public function save($diagnosis)
    {
        // 保存Diagnosis
    }
}

它不应该在：

findByCode()

中进行诊断。

235.4.6 Mapper层

Mapper负责Domain Object与Persistence Object之间的转换。

例如：

Diagnosis Domain Object
        ↓
DiagnosisMapper
        ↓
Persistence Data

反向：

Database Row
        ↓
DiagnosisMapper
        ↓
Diagnosis Domain Object

因此：

$Mapper:Domain↔PersistenceMapper:Domain\leftrightarrow Persistence$

Mapper解决的是结构转换问题，而不是认知问题。

235.4.7 View层

View负责最终展示。

例如Smarty模板：

diagnosis.tpl

接收：

diagnosis_code
problem
cause
recommendation
state
verification

然后生成HTML。

View不应该直接访问：

MySQL
PDO
RiskEngine
DiagnosisEngine
RepairEngine

正确的数据方向为：

$Service→Controller→ViewService \rightarrow Controller \rightarrow View$

235.5 ICAI完整数据流

ICAI系统的数据流必须与前面建立的认知链保持一致。

用户请求进入系统后：

$Request→ControllerRequest \rightarrow Controller$

Controller调用：

$Controller→ServiceController \rightarrow Service$

Service根据业务目标调用ICAI领域对象和Engine：

$Service→Domain Object→EngineService \rightarrow Domain\ Object \rightarrow Engine$

如果需要读取数据：

$Engine/Service→Repository→Mapper→PDO→MySQLEngine/Service \rightarrow Repository \rightarrow Mapper \rightarrow PDO \rightarrow MySQL$

数据库返回：

$MySQL→PDO→Repository→Mapper→Domain ObjectMySQL \rightarrow PDO \rightarrow Repository \rightarrow Mapper \rightarrow Domain\ Object$

然后继续计算：

$Domain→Engine→ResultDomain \rightarrow Engine \rightarrow Result$

结果返回：

$Result→Service→Controller→View→ResponseResult \rightarrow Service \rightarrow Controller \rightarrow View \rightarrow Response$

完整流程可以表示为：

$Request→Controller→Service→Domain→Engine→Repository→Mapper→PDO→MySQLRequest \rightarrow Controller \rightarrow Service \rightarrow Domain \rightarrow Engine \rightarrow Repository \rightarrow Mapper \rightarrow PDO \rightarrow MySQL$

然后：

$MySQL→PDO→Repository→Mapper→Domain→Engine→Result→Service→Controller→View→ResponseMySQL \rightarrow PDO \rightarrow Repository \rightarrow Mapper \rightarrow Domain \rightarrow Engine \rightarrow Result \rightarrow Service \rightarrow Controller \rightarrow View \rightarrow Response$

235.6 ICAI认知数据流与MVC数据流的结合

ICAI内部真正重要的不是MVC，而是认知数据流。

例如一个异常维护请求：

Request
↓
MaintenanceController
↓
MaintenanceService
↓
DetectionEngine
↓
Abnormality
↓
DiagnosisEngine
↓
Diagnosis
↓
RepairEngine
↓
Repair
↓
Execution
↓
Result
↓
Feedback
↓
Verification
↓
History
↓
Memory
↓
Experience
↓
Learning
↓
Update

MVC只负责把这条内部认知流程放入应用系统。

因此：

$MVC DataFlow≠ICAI CognitiveFlowMVC\ DataFlow \neq ICAI\ CognitiveFlow$

但是：

$MVC DataFlow⊃ICAI Application InvocationMVC\ DataFlow \supset ICAI\ Application\ Invocation$

两条流最终形成组合：

外部请求
    ↓
Controller
    ↓
Service
    ↓
ICAI认知流程
    ↓
Result
    ↓
Service
    ↓
Controller
    ↓
View
    ↓
用户

235.7 MVC与ICAI职责边界

为了避免系统后期出现严重耦合，需要建立明确的职责限制。

层	主要职责	不负责
Controller	请求控制	核心认知计算
Service	应用流程编排	数据库底层操作
Domain	领域对象	页面展示
Engine	确定性计算	HTTP请求
Repository	数据持久化	认知判断
Mapper	数据结构转换	业务决策
Persistence	数据库访问基础	认知计算
View	数据展示	数据库查询
MySQL	数据保存	认知推理

因此形成严格边界：

$Controller≠Service≠Domain≠Engine≠Repository≠ViewController \neq Service \neq Domain \neq Engine \neq Repository \neq View$

235.8 MVC中的ICAI核心调用规则

ICAI应用系统应遵循以下调用原则。

第一条：

$Controller→ServiceController\rightarrow Service$

Controller优先调用Service，而不是直接调用多个Engine。

第二条：

$Service→Domain/Engine/RepositoryService\rightarrow Domain/Engine/Repository$

Service负责组织应用过程。

第三条：

$Engine→Domain/RepositoryEngine\rightarrow Domain/Repository$

Engine可以读取必要的数据并进行计算，但不应该承担HTTP控制。

第四条：

$Repository→Mapper/PDORepository\rightarrow Mapper/PDO$

Repository只负责持久化。

第五条：

$Controller→ViewController\rightarrow View$

Controller将最终结果交给View展示。

由此形成：

$Controller→Service→Domain/Engine→Repository→MySQLController \rightarrow Service \rightarrow Domain/Engine \rightarrow Repository \rightarrow MySQL$

$MySQL→Repository→Domain/Engine→Service→Controller→ViewMySQL \rightarrow Repository \rightarrow Domain/Engine \rightarrow Service \rightarrow Controller \rightarrow View$

235.9 MVC与ICAI的工程意义

采用这种架构以后，ICAI可以同时保持两个独立体系。

第一体系是认知体系：

$Individual→Object→State→Relation→Knowledge→Goal→Capability→Method→Decision→Behavior→Action→Result→Feedback→Memory→Experience→Learning→UpdateIndividual \rightarrow Object \rightarrow State \rightarrow Relation \rightarrow Knowledge \rightarrow Goal \rightarrow Capability \rightarrow Method \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Result \rightarrow Feedback \rightarrow Memory \rightarrow Experience \rightarrow Learning \rightarrow Update$

第二体系是应用工程体系：

$Controller→Service→Domain→Engine→Repository→Persistence→MySQLController \rightarrow Service \rightarrow Domain \rightarrow Engine \rightarrow Repository \rightarrow Persistence \rightarrow MySQL$

两条体系通过Service和Domain进行连接。

最终：

$ICAI=Cognitive Model+Domain Model+Calculation Engine+Application Architecture+PersistenceICAI = Cognitive\ Model + Domain\ Model + Calculation\ Engine + Application\ Architecture + Persistence$

其中MVC属于：

$Application ArchitectureApplication\ Architecture$

而不是认知本体。

235.10 PHP工程映射

在PHP工程中，可以形成如下目录结构：

app/
├── controllers/
│   ├── CognitiveController.php
│   ├── GoalController.php
│   ├── DecisionController.php
│   └── MaintenanceController.php
│
├── services/
│   ├── IndividualService.php
│   ├── GoalService.php
│   ├── DecisionService.php
│   ├── BehaviorService.php
│   ├── MemoryExperienceService.php
│   └── DiagnosisRepairService.php
│
├── models/
│   ├── Individual.php
│   ├── Object.php
│   ├── State.php
│   ├── Relation.php
│   ├── Goal.php
│   ├── Capability.php
│   ├── Method.php
│   ├── Decision.php
│   ├── Behavior.php
│   ├── Action.php
│   ├── Result.php
│   ├── Feedback.php
│   ├── Memory.php
│   ├── Experience.php
│   ├── Risk.php
│   ├── Conflict.php
│   ├── Abnormality.php
│   ├── Diagnosis.php
│   ├── Protection.php
│   ├── Repair.php
│   └── Learning.php
│
├── engines/
│   ├── StateEngine.php
│   ├── RelationEngine.php
│   ├── KnowledgeEngine.php
│   ├── DecisionEngine.php
│   ├── DetectionEngine.php
│   ├── DiagnosisEngine.php
│   ├── ProtectionEngine.php
│   ├── RepairEngine.php
│   ├── LearningEngine.php
│   └── CognitiveEngine.php
│
├── repositories/
│   ├── IndividualRepository.php
│   ├── ObjectRepository.php
│   ├── StateRepository.php
│   ├── RelationRepository.php
│   ├── GoalRepository.php
│   ├── DecisionRepository.php
│   ├── DiagnosisRepository.php
│   └── RepairRepository.php
│
├── mappers/
│   ├── ObjectMapper.php
│   ├── GoalMapper.php
│   ├── DiagnosisMapper.php
│   └── RepairMapper.php
│
└── views/
    ├── cognitive/
    ├── goal/
    ├── decision/
    └── maintenance/

这个结构不是要求所有项目必须严格采用相同目录，而是建立职责边界。

例如：

MaintenanceController
        ↓
DiagnosisRepairService
        ↓
DetectionEngine
        ↓
Abnormality
        ↓
DiagnosisEngine
        ↓
DiagnosisRepository
        ↓
MySQL

它能够把第232章建立的维护体系、第233章建立的关系体系、第234章建立的数据生命周期体系统一到MVC应用结构中。

235.11 ICAI与传统MVC的关键区别

传统MVC经常把大量业务逻辑直接放入Model。

ICAI不能采用这种模糊方式。

ICAI必须进一步区分：

$Model=Domain Model+Persistence ModelModel = Domain\ Model + Persistence\ Model$

同时：

$Business Process→ServiceBusiness\ Process \rightarrow Service$ $Calculation→EngineCalculation \rightarrow Engine$ $Persistence→RepositoryPersistence \rightarrow Repository$ $Presentation→ViewPresentation \rightarrow View$

因此ICAI实际上形成了比传统MVC更加明确的工程分层。

其核心不是增加目录，而是避免职责混合。

例如：

Controller中不能直接进行概率计算
View中不能直接查询数据库
Repository中不能进行诊断
Engine中不能负责页面输出
Mapper中不能进行决策
Service中不能取代Engine的计算规则

这样才能保证系统长期扩展时不会形成一个巨大的混合类。

235.12 MVC与非大模型ICAI架构

ICAI的MVC实现不依赖大模型。

其认知过程仍然基于：

对象；
属性；
状态；
关系；
条件；
规则；
知识；
历史；
记忆；
经验；
概率；
离散计算；
确定性算法；
PHP OOP；
MySQL数据。

系统核心计算仍然是：

$Input+Object+State+Relation+Knowledge+Condition+Rule→Calculation→OutputInput + Object + State + Relation + Knowledge + Condition + Rule \rightarrow Calculation \rightarrow Output$

MVC只负责把这些计算能力组织成可以运行的Web应用。

因此：

$MVC≠AI ModelMVC\neq AI\ Model$

也不存在：

$MVC→LLMMVC\rightarrow LLM$

ICAI的认知能力来自其自身建立的对象、关系、规则、状态、记忆、经验和计算机制。

235.13 本章统一架构

经过前面各章的定义，ICAI现在可以形成统一的工程架构：

                    User / External Request
                              │
                              ▼
                         Controller
                              │
                              ▼
                           Service
                              │
             ┌────────────────┼────────────────┐
             │                │                │
             ▼                ▼                ▼
          Domain           Engine          Repository
             │                │                │
             │                │                ▼
             │                │              Mapper
             │                │                │
             │                │                ▼
             │                │               PDO
             │                │                │
             │                │                ▼
             │                │              MySQL
             │                │
             └────────┬───────┘
                      ▼
                    Result
                      │
                      ▼
                   Service
                      │
                      ▼
                  Controller
                      │
                      ▼
                    View
                      │
                      ▼
                  Response

而ICAI内部认知链为：

Individual
↓
Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge
↓
Need
↓
Goal
↓
Capability
↓
Method
↓
Decision
↓
Behavior
↓
Action
↓
Execution
↓
Result
↓
Feedback
↓
History
↓
Memory
↓
Experience
↓
Learning
↓
Update

维护过程则形成：

State
↓
Detection
↓
Risk / Conflict / Abnormality
↓
Diagnosis
↓
Protection / Repair
↓
Execution
↓
Result
↓
Feedback
↓
Verification
↓
History
↓
Memory
↓
Experience
↓
Learning
↓
Update

最终，MVC把外部应用请求与ICAI内部认知系统连接起来：

$External Request→MVC→ICAI→MVC→External ResponseExternal\ Request \rightarrow MVC \rightarrow ICAI \rightarrow MVC \rightarrow External\ Response$

235.14 本章总结

MVC解决的是应用程序如何组织的问题。

ICAI解决的是系统如何形成个体化认知、计算、行为、反馈、记忆、经验、学习与维护的问题。

二者不能混为一谈。

本章建立了以下统一关系：

$Controller→Service→Domain/Engine→Repository→MySQLController \rightarrow Service \rightarrow Domain/Engine \rightarrow Repository \rightarrow MySQL$

以及：

$Controller→Service→Domain→Engine→Result→Controller→ViewController \rightarrow Service \rightarrow Domain \rightarrow Engine \rightarrow Result \rightarrow Controller \rightarrow View$

其中：

Controller负责请求入口与应用控制；

Service负责应用流程编排；

Domain负责ICAI核心对象；

Engine负责确定性认知计算；

Repository负责持久化；

Mapper负责领域对象与数据库结构转换；

View负责结果展示；

MySQL负责数据持久化。

因此，ICAI最终不是简单的MVC程序，而是：

$ICAI Application=MVC+Domain+Engine+Service+Repository+PersistenceICAI\ Application = MVC + Domain + Engine + Service + Repository + Persistence$

其核心原则是：

$认知属于ICAI认知属于ICAI$ $计算属于Engine计算属于Engine$ $流程属于Service流程属于Service$ $请求属于Controller请求属于Controller$ $展示属于View展示属于View$ $持久化属于Repository持久化属于Repository$

由此，第159章以来建立的Capability、Method、Decision、Behavior、Feedback、Memory、Experience、Risk、Conflict、Diagnosis、Repair、Learning、Engine、Repository、数据库关系与生命周期，最终能够进入一个具有明确职责边界的实际PHP MVC工程系统。

第235章 MVC架构与ICAI

第235章 MVC架构与ICAI

235.1 MVC定义

235.2 MVC职责

235.2.1 Controller职责

235.2.2 Model职责

235.2.3 View职责

235.3 ICAI与MVC

235.3.1 MVC与ICAI核心对象对应关系

235.4 系统分层

235.4.1 Controller层

235.4.2 Service层

235.4.3 Domain层

235.4.4 Engine层

235.4.5 Repository层

235.4.6 Mapper层

235.4.7 View层

235.5 ICAI完整数据流

235.6 ICAI认知数据流与MVC数据流的结合

235.7 MVC与ICAI职责边界

235.8 MVC中的ICAI核心调用规则

235.9 MVC与ICAI的工程意义

235.10 PHP工程映射

235.11 ICAI与传统MVC的关键区别

235.12 MVC与非大模型ICAI架构

235.13 本章统一架构

235.14 本章总结