MVC 模式
提到图形设计,我不可能知其不可为而为之,因为这不是我所擅长的。然而,给我一个其他有天赋的人拼凑好的设计,我可以用那个界面完成您想完成的任何事情。因而,能够分解好一个基于网络的应用程序的设计相关的工作是非常有利的,这样,设计人员、编码人员和 DBA 都可以做他们各自擅长的事情。这就是 MVC 模式的实质,它将一个项目分解成三层。
引用:
模型-视图-控制器的定义
按照定义,模式是多年演化而来的做事情的方法,因为它们是某一问题的好的解决方案。模型-视图-控制器 (MVC) 模式也不例外。由于具体的创建过程有所不同,所以您偶尔会发现一些定义之间存在差异。例如,一些对 MVC 的定义中将控制器的角色定义成简单地改变状态,其所有的业务逻辑都集成在模型层。最后,惟一重要的事情是,应用程序以最有效的方式完成了您想要它完成的事情。
模型层 由真实数据的表示组成。例如,在我们的提要阅读器项目中,包含了用户、提要和提要条目。它们在数据库中的表示总体上 “建模” 了它们的结构,从而组成了模型层。
视图层 由一些逻辑组成,这些逻辑实际上定义了显示的数据如何表现。它并不决定这些已显示的数据是什么,而仅仅是它们如何表现。理想状态下,该模块不包含任何逻辑,只接受所给信息,并把它们显示出来。
控制器 实际上定义了数据是什么。事实上,控制器是所有逻辑存放的地方。在 Zend 框架中,该层控制了要执行的行为。例如,如果我想要显示单个提要条目对象,那么职责被解析为:提要条目对象具有一个控制器,该控制器定义了当调用显示行为时所发生的事情。该显示行为回调以从模型(或者说是数据库或其他持久性存储器)中获取需要的数据,然后将这些字段 —— 如标题、内容、持久链接等 —— 填入视图中,该视图可以将其简单地显示在浏览器中。
应当承认,对大多数程序员来说,这是一次启程。尽管存在对象,但 PHP 始终是一门过程化的语言。尽管如此,这项交易是绝对值得的。按照 MVC 模式构建应用程序远要比构建一个里面乱成一团的应用程序要简单的多。
现在,让我们来看看您需要做些什么。