网络编程 Asp编程 Php编程 CodeIgniter .Net编程 Xml编程 VB编程 asp.net(c#) 支付接口 PayPal 支付宝 iOS开发 Android Xamarin.Android Android Studio ORM Dapper 其他 IbatisNet MVC WCF 微信开发 微信小程序 WPF Solr SignalR CMD xarmin.android Tesseract ASP.NET Core Vue VsCode JAVA Tomcat spring mvc MyBatis JDBCTemplate Dubbo swagger IDEA HSSFWorkbook Spring Cloud HBuilderX AI .net core AutoMapper SqlSugar IdentityServer4 Razor Blazor Redis Quartz NPOI HSSFWorkbook DevExpress 分布式存储技术 LINQ RabbitMQ 淘宝客 Dockerfile cron表达式 阿里云OSS服务 JWT SolrNet AngleSharp Elasticsearch perl Golang AutoJs adb appium python bat c Smobiler Power apps Power Bi 开发PCF RTSP视频推流服务器 OutSystems echarts 服务器 Web服务器 Ftp服务器 Mail服务器 Dns服务器 Win服务器 Linux服务器 安全防护 系统激活 wifi SVN服务器 虚拟机 Flash Media Server IIS服务器 ngrok服务器 分布式系统 版本控制系统 Git 监控系统 Nginx zookeeper SolrCloud node Nacos Docker PHP服务器 Web前端 Jquery js AJAX EasyUI CSS HTML 自适应/响应式 HTML5 地图API MP3 编辑器 UEditor 插件 highcharts SVG Bootstrap layer Element React Ant Design Nextjs yarn 软件开发 winform BAT编程 项目管理 数据模型工具 PowerDesigner PDMan UML流程图 物联网 开发工具 Flash工具 VS2010 VS2012 VS2017 VS2019 wget 抓包工具 Eclipse IntelliJ Idea VS2022 cmder 网络攻击 CC攻击 数据库 Access Mssql Mysql SQLite php_sqlsrv Oracle MongoDB NOSql Redis 设计在线 酷站推荐 网页设计 WEB标准 视频处理 设计活动 网站运营 建站经验 策划盈利 SEO优化 网站推广 淘宝秘籍 短信通道 新闻资讯 业界动态 收购融资 门户动态 搜索引擎 网络游戏 电子商务 广告传媒 厂商开发 手机应用 各业合同 法律法规 名词解释 钓鱼技巧 百科知识 理财 生肖星座 操作系统 windows xp sp3 windows server 2008 win10 windows server 2016 windows11 Linux 图形图像 Photoshop教程 illustrator教程 CAD设计教程 开放平台 腾讯 新浪 手机应用 小米手机 魅族手机 装修 壁纸施工 防水技术 室内平面设计 蹲便器 卫生间 CAD室内三维图形 装修知识 学生学习资料库 小学生学习资料库 初中生学习资料库 高中生学习资料库 搜索引擎 百度 360 搜狗 神马 头条 集群搭建 Hadoop集群 k8s集群 平台架构 SaaS 测试工具 JMeter 大数据 站长在线 好站推荐 联盟资讯 联盟新闻 联盟介绍 联盟点评 网赚技巧
隐藏

CodeIgniter控制器之业务逻辑

发布:2014/7/10 16:01:52作者:管理员 来源:本站 浏览次数:1662

前面对公用控制器按模块分发,方便对特定模块的控制,而具体的实现类则是放在library中。那放在library中是否合适呢?以及控制器中更多的业务逻辑该放在哪里?
先说下对CI中几个文件夹的理解
helpers、libraries: 存放一系列辅助函数、辅助类,用来辅助控制器、业务逻辑实现功能。他们中的方法应当尽量避免与CI依赖,依赖越紧越难以复用。以邮件发送为例,发送邮件时很多参数是不变的,如编码、协议、端口等,我们可能会在config下进行配置这些参数,然后library封装一个邮件发送的类,并在其中获取CI实例后读取这些参数。此时就出现了与CI实例的依赖,该类就只能在CI框架中使用,其他系统要用到,就只能重写了,没达到复用的目的。如果发送的类只是接收参数,并封装发送方法呢?所以说,尽可能的让helpers、libraries变的简单,职责变得单一。
controllers: 控制器目录。控制器主要用来接管程序,起到连接的作用。通常情况下,我们会把业务逻辑写在action中。但随着业务变得复杂,action代码将越来越臃肿,难以维护。
models: 模型目录。CI的模型的主要职责就是和数据库打交道,获取数据。很多时候也会把业务逻辑放在模型中,但业务逻辑与模型实际上是两种东西了。模型只是获取数据,业务逻辑可能是把这些数据根据业务需要进行组合,组合方式可能有很多种,放在模型中会让模型难以维护且不利于复用。说个碰到的例子,对数据按一定条件做缓存,获取数据和缓存结果两个流程写在同一个方法中,但同样的数据需要做另一种形式的缓存时发现,获取数据的方法就没法重用了。
third_party:第三方类库目录。拿到一个类库后不要直接使用, 可以在library中进行一次封装,让其更适应于系统,其他人使用起来难度也会降低。
可以发现,每个文件夹都有自己的职责,每个模块都有自己的家,都有自己的职能。那业务逻辑该怎么办?
既然这样, 我们也应该给业务逻辑安个家,建立一个唯一的目录用来存放业务逻辑,暂且命名为service。控制器主要负责接收参数并调用service,service来调用模型,各层各尽其责。
下面看看怎么实现:
我们可以重写MY_Load,增加service方法,直接通过$this->load->service('user_service');来调用。
但业务逻辑很多都需要获取CI实例,这里可以参考模型的方法,core建立一个MY_Service,其他service均继承该类,这样子service里用法就跟控制器里一样了。
PHP复制代码
 
class MY_Service
{
    public function __construct()
    {
        log_message('debug', "Service Class Initialized");
    }
 
    function __get($key)
    {
        $CI = & get_instance();
        return $CI->$key;
    }
}
 
复制代码

其实主要思路还是需要有一层用来处理业务逻辑,java中都有这一层。随着对CI的不断熟悉,发觉这里需要这一层,达到解放控制器和模型的目的。和这种类似的做法还有很多,如果系统中有很多地方需要用到web service 或者说cache之类的,其实也可以按照上面的思路单独放在一个文件夹中处理,方便管理。