php框架Model设计参考

admin 2015年08月11日 PHP学习 761次阅读 查看评论

  Model设计参考

  在MVC中,Model排第一,是有一定暗示的。一是Model是整个架构中,代码量最大,复用程度最高, 也是最体现程序员设计功力的地方。 二是View和Controller相对于Model而言,在实际开发中,复用程度不高,逻辑复杂程度较低。 可以说,Model设计得好,整个MVC就好,应用开发起就顺。

  因此,这一节将以Model为核心,来讲MVC的设计。 实话说,MVC尽管提出了Model View Controller的划分思想,但到了具体实操中,并不是很好把握的。 下面介绍的设计参考,也仅仅是个人在实际项目中的一些体会和想法,仅作参考。 在具体设计中,可以后把握这么几点:

  Model应当集中整个应用的数据和业务逻辑

  应用当中涉及到的所有业务对象都应尽可能抽像成Model。 如,博客系统当中,文章要抽象成Post,评论要抽象成Comment。 而相关的业务逻辑,如发布新文章可以用 Post::create() ,删除评论可以用 Comment::delete()。 这样子整个应用就显得很清晰明了。

  基础Model应当尽可能细化

  在一个应用中,特别是对于大型复杂应用,Model间关系可能比较复杂。在构造应用时,特别是基础Model时, 要从足够小的粒度来设计。 此时,就要考虑采取继承、封装等措施了。 比如,一个博客文章Post,一般包含了若干标签,在页上一般写在作者、日期等Post字段的旁边。 从逻辑上来看,把标签作为Post的一个属性,是说得通的。 但是如果把标签作为一个属性像标题、正文等字段一样依附于Post。那么在有的功能上,实现起来是有难度的。 比如,客户要求,当一个Post含有标签 “yii, model” 时,可以点击 “yii” , 然后系统列出所有具标签中含有 “yii” 的文章。

  为了实现这个功能,正确的设计是单独将标签抽象成Tag。这样,Post和Tag是多对多的关系, 即一个Post有多个Tag,一个Tag也对应多个Post。这个多对多关系可以通过一张数据表 tbl_post_tag 来表示。 接下来,为Post增加 Post::getTags() 方法,并通过 tbl_post_tag 表来查询当前Post的所有标签。 同时,为Tag增加Tag::getPosts() 方法,也通过 tbl_post_tag 表来查询当前Tag对应的文章。 这样,就具备了实现客户要求的新功能的基础。

  因此,在Model设计上,要以尽量小的粒度进行设计。一般而言,粒度越小,复用的可能性就越高。

  有的读者可能会问了,既然要求粒度尽可能地小,那么,Post是不是也应当再细化,把段落抽象为Model? 是否有这个必要,看客户需求。一般情况确实没有这必要,如果这么做,那是不是再以句子为单位进行抽象? 但如果客户要求这个博客系统的评论是针对段落进行的评论的, 要将评论显示在对应的段落旁边,甚至显示每个段落评论人次等功能。那么就需要把段落抽象成Model了。

  分层次设计Model

  从设计流程上,数据库结构设计与Model的设计是紧密相关的。先有数据库结构设计,后有Model设计。 在设计数据库结构的时候,也是在设计Model。 一般而言,最单元、粒度最小的Model就是根据每个数据库表所生成的Model,这往往是个Active Record。

  比如标签的问题,在数据库存储过程中,Post和Tag是分开存的,而且这两个表的字段,没有冗余。tbl_post_tag 表也只记录他们的ID,没有实质内容。

  在获取数据渲染视图,向用户展现时,这两个Model及他们的字段,是完全够用,且没有冗余的。

  那么,能不能说 Post 和 Tag 这两个Model是够用的呢?显然还不够。

  当用户在创建文章、修改文章、审核文章时,需要采用一个表单来显示来收集用户输入。 其中,对于标签的采集,一般是一个长条的文本框,让用户一次性输入多个标签,并以 , 等进行分隔的。

  但是,这个文本框没有一个字段与之进行对应。我们也没办法对这个字段的用户输入进行任何的验证、预处理。

  因此,Post的功能是不够用的。不够用怎么办?那就加吧。但直接在 Post 里面加个 public $tagString 并不好。 毕竟只是在使用表单时,才会有这个问题,其他场合,这个字段是没用的。

  这种情况下,一般使用继承:

1
2
3
4
5
6
public class PostForm extends Post{ 
public $tagString;

 ... ...
 
 }

  这样,当控制器发现用户在创建、修改、审核文章时,可以使用 PostForm Model来渲染视图了, 而其他场合则仍使用Post。这样就在需要时,增加了一个 tagString 的字段用于收集用户输入的标签。

  在具体设计过程中,由于Model本身就会包含很多代码,因此,要多使用这继承等手段,把代码组织好。

  仔细为Model方法命名

  由于Model的代码量比较大,又集中了大量的逻辑,因此,会在一个Model中有大量的方法。仍然以Post为例, 会涉及到创建、审核、发布、回收等流程,相关的方法比较多,在命名上要用心。 可能会涉及到的、名字又比较接近的方法就有:

  •   getPrevPost(),前一篇文章,用于导航

  •   getNextPost(),下一篇文章,用于导航

  •   getRelatedPosts($n = 10),获取相关的N篇文章,用于相关文章推荐列表

  •   getPostsOfAuthor($n = 10),获取同一作者的N篇相关文章,用于作者文章列表

  •   getLatestPosts($n = 10),最新的N篇文章,静态方法,用于文章列表或RSS输出

  •   getHotestPosts($n = 10),最热门的N篇文章,静态方法,用于热门文章列表

  •   getPublishPosts($n = -1),获取已经发布的N篇文章,静态方法,用于文章列表

  •   getDraftPosts($n = -1),获取未发布的N篇文章,静态方法,用于作者页面

  这里只是一些获取其他Post的方法,命名比较合理,一看就知道意思。 而且全部写成getter的形式,可以使用读取属性的方式进行访问。

  不单单是在Model方法的命名上要用心, 在变量名、类名、方法名等的命名上,也要养成习惯,形成规律。 不要图一时之快,胡乱起名。否则,出来混,迟早要还的。

« 上一篇 下一篇 » admin原创文章,转载请注明出处! 标签:php框架Model设计参考mvc

相关日志:

«   2019年11月   »
123
45678910
11121314151617
18192021222324
252627282930
控制面板
您好,欢迎到访网站!
  [查看权限]
网站分类
文章归档
网站收藏
友情链接
图标汇集
  • 又拍云
  • 订阅ipvb的RSS 2.0聚合