在使用模型-视图-控制器设计模式的基于 Web 的应用程序中,与处理表单提交相关的逻辑似乎属于模型层和控制器层之间的某个位置。在复杂表单的情况下尤其如此(即表单处理远远超出简单的 CRUD 操作)。
对此进行概念化的最佳方法是什么?表单只是模型和控制器之间的一种粘合剂吗?还是形式逻辑完全属于 M 或 C 阵营?
编辑:我了解 MVC 应用程序中的基本信息流(请参阅chills42 的答案以获取摘要)。我的问题是表单处理逻辑属于哪里 - 在控制器、模型或其他地方?
在使用模型-视图-控制器设计模式的基于 Web 的应用程序中,与处理表单提交相关的逻辑似乎属于模型层和控制器层之间的某个位置。在复杂表单的情况下尤其如此(即表单处理远远超出简单的 CRUD 操作)。
对此进行概念化的最佳方法是什么?表单只是模型和控制器之间的一种粘合剂吗?还是形式逻辑完全属于 M 或 C 阵营?
编辑:我了解 MVC 应用程序中的基本信息流(请参阅chills42 的答案以获取摘要)。我的问题是表单处理逻辑属于哪里 - 在控制器、模型或其他地方?
我想说这可能应该被视为两个独立的行动......
在泛型方面,我倾向于将每个动作视为部分之间的信息。完整系列的消息将是这样的......
虽然一开始使用 V -> C, C -> M, M -> C 的想法看起来不错,但对表单的任何更改都需要弄乱控制器+模型+视图。应该避免这种情况以保持应用程序逻辑简单。这是一个非常简单的框架扩展,它通过将表单处理逻辑委托给一个单独的类并保持 MVC 架构来处理应用程序逻辑,从而使处理 Web 表单处理变得非常容易。
对于您需要处理的每个表单,创建一个从通用“webform”类或 codeigniter 模型类派生的类。将 validate()、process()、display() 等方法添加到此类。
在控制器中,代码变成了这样。
class User_controller
{
function login()
{
$form = new LoginForm(); // this is the class you would create
if ($form->validate())
{
$data = $this->user_model->getUserData( $form->userid );
// form processing complete, use the main "user" model to fetch userdata for display,
// or redirect user to another page, update your session, anything you like
} else {
$form->display();
}
}
}
表单类中的 display 方法加载它自己的视图,并根据需要填充回发数据。通过使用上述,有几个优点:
如果表单显示或处理需要更改,则无需更改主控制器。
你也不需要改变你的用户模型
控制器保持干净并处理主页逻辑
用户模型保持干净并且只与数据库交互
框架本身可以更新,以便可以使用加载 web 表单
$this->load->form("登录"); ……
但是,这只是对 codeigniter 团队有用的建议。
同意chills42,但会尽可能多地添加到模型中。
当用户提交 (V->C) 时,它将被提交给某个控制器,我认为最好控制器只是充当调度程序来决定接下来会发生什么,可能基于一些简单的数据点。让模型有一个方法(通常不是严格的 ORM 或基于活动记录)处理原始数据并在适当时将其保存到数据库中,然后简单地返回状态或抛出错误。
表单处理应该在模型中进行,因为这是应用程序的层,它通过视图的方式从控制器接收和处理数据。控制器移动它,但至于实际的代码执行,它应该发生在你的模型中。