商品管理核心部分.pdfVIP

商品管理

删除商品

控制器

增加一个商品删除控制器动作！

GoodsController.class.php

该动作应该获得当前需要删除的商品ID，调用模型，利用该ID，删除商品数据！

模型

需要提供GoodsModel：：delGoods()方法

GoodsModel.class.php

视图层

没有视图层的工作！

其他

修改请求到删除操作的地址

列表页的视图部分代码即可

goods.view.html

更新商品信息

展示更新表单操作

控制器

需要在商品控制器类中，增加一个动作，用于展示表单页面

GoodsController.class.php

需要，得到编辑商品的id，获得商品数据，展示表单页面，商品数据出现在表单页面内！

模型

GoodsModel中提供getByID的方法

GoodsModel.class.php

视图，view

提供一个模板，存在一个表单

为表单指定请求地址：

将ID作为隐藏域存在

其他

需要列表也，为每条商品增加一个可以指向更新动作的：

goods.view.html

更新数据

控制器

Goods控制器的update动作

收集表单数据，调用模型完成更新，跳转

GoodsController.class.php

模型

提供方法，通过数据，拼凑update语句，完成更新

GoodsModel.class.php

视图

没有视图工作

框架的概念

将，mvc架构代码中，底层的，与业务逻辑相关的分开处理。保存到不同的内，便

于管理！

如果将，所有的公共代码都分离出来，公共代码可以作为其他项目的底层代码！形成一个小

型的框架！

没有业务逻辑的底层代码，就是框架！

以shop项目为例：

做如下的划分：

框架和逻辑代码分割

分成，业务逻辑一部分（应用程序，application），框架底层代码一部分（框架Framework）

application中mvc三部分的分割

在项目业务逻辑application中，将控制器，模型，和视图层模板文件，分子保

存：

业务逻辑的平台的分割（前台和）

业务逻辑和展示上的分割，但是前后是通过同一个数据进行联系的！

模型是基于表创建的，前台代码应该共享模型！

控制器：

视图：

模型层前（其他所有平台）共享：

整体的结构

shop

application业务逻辑（应用程序）

controller控制器

front前台控制器

bac控制器

view视图

front前台视图

bac视图

model模型

framework框架（底层代码）

index.php文件

例子

利用现在的结构，完成商品管理

假设前台的操作！

1，控制器路径问题。

单纯通过控制器名字，不能唯一确定某个控制器，增加了平台的概念！

因此，在请求时，应该再增加一个平台（platform）参数，表示所请求的平台！

一个请求需要三个参数：

p:平台

c:控制器

a:动作

文件，需要获得三个参数

index.php

利用平台，找到控制器类文件：

2，控制器载入模型文件

application/controller/front/GoodsController.class.php

继承基础模型时，也应该使用正确路径

application/model/GoodsModel.class.php

在得到mysqlDB类时错误

framework/Model.class.php

3,载入视图问题

application/controller/front/GoodsController.class.php

增加路径的管理

单，可保证所有的当前路径都是以文件为标准！

典型的项目中，路径如何处理？

典型，是使用常量，进行路径的保存。并且通常都使用绝对路径！

index.php

在需要的地方，是该常量完成：

增加类的加载（自动加载机制）

index.php

根据类名，到不同的中，将类