涉及 CodeIgniter 标签的文章 所有标签


Codeigniter扩展-支持分库分表
8年前
  • 3
  • 0

Codeigniter扩展-支持分库分表

针对CI模型的分库分表扩展

就CI在对于一些分库分表这块并没有支持而做的扩展

涉及以下文件

  • application/libraries/MY_Profiler.php (仅仅为了支持在调试模式的SQL日志输出而重写了_compile_queries方法)
  • application/core/MY_Model.php

http://paperen.com/file/198

使用情景描述

在一些大型项目中可以会遇到DB将某些会出现大量数据的表拆分到多个表甚至是多个数据库中多个表

比如:用户数据

在单库单表的情况下只使用user表存放数据

uid——username——email——password

但随着数据量增加后续会采取分表存放数据比如创建多个表,user0,user1,user2,user3,而同时有一个主表user_index记录用户的id与username,user_index作为用户的一个索引

uid——username 1——paperen 2——paperen3 3——paperen4

关于这三个用户的详细信息是分散到不同表存储的,如何知道是哪个表,则使用求余的方法 公式为:uid%4 通用公式为:id%(分表总数)

那对于paperen4这个用户他的详细数据是放在3%4=3,也就是user3表里面

阅读更多
通过hook设计出更方便的令牌
12年前
  • 0
  • 0

通过hook设计出更方便的令牌

之前同事做每周分享时说了thinkphp的令牌,只需要在视图中写上__TOKEN__那么到时就会自动转换成一个隐藏域,顿时觉得很方便于是那时就按照这种思路在CI的基础上扩展了这种产生令牌的方式

记得之前发表过关于hook令牌的两篇文章

如果你还不清楚什么是钩子的话,建议花点时间看看与写写,而令牌其实就是为了防止表单重复提交的,不知道的自己补补

要在CI的基础上实现这种扩展,paperen我首先想到的就是利用钩子,利用在视图输出前的钩子检测文本中是否有__TOKEN__关键字,有则创建一个令牌并用隐藏域替换掉

阅读更多
一个基于Hex-HMVC的模型扩展
12年前
  • 3
  • 2

一个基于Hex-HMVC的模型扩展

为什么要进行这个扩展?

在使用hex提供的HMVC扩展方案以来在模型方面一直有疑问,怎衡量模型放在相应modules/models下还是放app目录/models下?比如模块1中要调用user模型的get_all方法获取所有用户数据 模块2也要获取这些数据 那么若模块1,2的模型中都创建一个user模型实现各自的get_all方法会不会显得没有重用的味道?

通过在微博上询问@hex hex的评论启发了我,他说“感觉还需要有个模型继承的功能吧” 没错继承

于是paperen我尝试按照这个概念去在hex的HMVC基础上扩展这个功能,从而达到这个继承的模式

涉及文件

就一个MY_Loader.php

阅读更多
关于控制器与模型间的一些想法
13年前
  • 0
  • 0

关于控制器与模型间的一些想法

用CI也有一段时间了,感觉paperen我也挺喜欢CI的,因为觉得上手真的很容易也很方便,暂时还不会考虑其他框架。不过通过这段时间的使用,加上同事比较多疑问(也算是好事吧),自己也有点对CI中控制器与模型部分使用产生些少疑问,特别是模型,因为之前的开发就带来一些比较混乱的状况,老实说之前写的代码比较糟糕。

20111122011355

很多疑问都是产生在控制器与模型之间的,疑问最严重的是模型的重用性(况且可以这么说吧),平平君与奇奇君本来是分开一人负责一块功能的,但是免不了要涉及一些公用的模型,这就导致了一些不能避免的问题,平平君要与奇奇君协商某个公用的模型方法,但是别扭的是前者可能额外附件一些条件,比如要查询state为3的记录而后者则又会附加其他限制条件,而且paperen不太同意在控制器中对模型进行控制(或者下面的例子展示后你就明白什么意思),结果要写一个能符合两者需求的模型方法,在这个模型方法中写了比较复杂的逻辑,本来比较简单的模型突然看到一段复杂的逻辑,这个真的是我不想要的,paperen提议的是即使你查询的条件不同的话就可以考虑分出来单独作为一个方法了,而不要花太多时间在万能的模型方法,因为那可能会增加了模型的复杂度或者增加了控制器与模型的耦合度。说了这么多还不如看个例子吧。

阅读更多
CI脚手架(当作是圣诞礼物好了)
12年前
  • 2
  • 0

CI脚手架(当作是圣诞礼物好了)

自己设计的一个基于codeigniter的脚手架,能生成原始模型文件与模块目录,你只需要扩展与完善功能即可,减少编写重复模式的代码 在CI的基础上也做了一些扩展 包括一些开源的扩展与自己编写的扩展

git上的项目地址 https://github.com/paperen/ci-scaffold

部分截图

ci-scaffold界面
ci-scaffold界面

阅读更多
CI模型扩展成调用即加载(含缓存模式)
12年前
  • 2
  • 0

CI模型扩展成调用即加载(含缓存模式)

关于CI中的模型的标准用法是先要load然后才能使用的,基于这种调用模型的做法长久下来就让paperen觉得麻烦,一开头就得要将用到的模型手动全部load过来,当然这种算是比较苛刻的做法也是有它的理由,毕竟这就清楚这部分引用了哪些模型与减少加载多余模型的机会。

// 加载用户模型
$this->load->model('user');
// 获取所有用户数据
$this->user->all( $per_page, $offset );

CI的模型文档 http://ellislab.com/codeigniter/user-guide/general/models.html

在开始后续内容之前还是声明一下

调用即加载

paperen想象中要达到的目的就是

// YY一下要实现的调用写法
$this->model_user_all( $per_page, $offset );

我们不需要再先load,调用的时候就会自动加载,格式必须是model_{模型名称}_{方法}( 参数1, 参数2, ... )

如果你觉得这样不适合自己使用就不用往下看了

附带查询缓存的概念
// YY一下要实现的调用写法
$this->model_cache( 'model_user_all', $per_page, $offset );

之前也有一篇关于查询缓存的文章 http://paperen.com/post/ci-querycache-extend

其实就是避免不同模块执行了相同的SQL语句,模块之间的数据完成是可以公用的,而这个querycache就是桥梁,也算是一种解决办法吧,不过在这次扩展中querycache将成为其中的组件,对于我们来说它完全是透明的

强调一下 对插入与更新、删除的动作不要使用查询缓存 paperen在代码中并没有限制这个也就是意味着你可以使用model_cache来完成update、insert、delete等操作,但是这有什么意义呢。。。

阅读更多
关于hook一些研究(CI)
12年前
  • 5
  • 2

关于hook一些研究(CI)

近来因为布置了每个人了解一个框架,paperen依旧选择CI(从这方面也可以看出我很专一…)作为进一步研究,所以paperen又再次看了它的核心代码,而看到hooks的实现时不禁有感而发,感叹之前自己试着在CI的基础上设计一个hook的做法实在太SB。

paperen并不想放什么概念的跟大家分享,而是从自己博客开始。

你看到博客的右边栏,在进入某篇文章详细时是会多出这个附带图片的栏目,就是将该文章中所有的附带图片在此用缩略图形式展现,方便浏览者点击查看。这个地方就是应用了钩子,或许说到这里你还是很模糊,但下面就会进行更多解析。

阅读更多