CodeIgniter4框架中的Entity類

CodeIgniter4和CI3相比,框架更加的厚重丰满了,我不喜欢如此的厚重,显得蠢笨。相对而言还是喜欢CI3的轻量简洁。然而无论是否喜欢,该用还是要用的。

CI4和CI3相比,MVC结构发生了一些变化,多了Entity类,也就是在原来经典的Model、View、Controller的基础上,添加了一个层次,可以说是MEVC结构了。

多出来的这个Entity在我上一个项目的开发时,并没有使用,当时为了追求速度,懒得深入学习、也完全没有时间学习CI4,所以仍然保持着CI3的喜欢进行开发。这是允许的,CI4的文档中也明确的提及:虽然引入了Entity类,然而如果个人习惯使然,可以忽略它继续沿用曾经的MVC模式。

但是这个Entity类的引入实际上是非常实用的,它可以被翻译成“实体类”,但这样翻译稍微有一些晦涩,我更喜欢把它称为“实例类”,虽然我的叫法不标准,但是对自己而言更容易理解一些。

经典的MVC模式中的Model层,也就是模型层,主要是对数据库的操作、将数据库中的数据结构具象成数据模型,方便理解和使用。

然而如果只使用Model类进行数据的具象,有一个比较大的弊端:分不清楚Model中的方法究竟是针对数据表的、还是针对实例对象的。例如下面的代码:

$userInstance = $userModel->fetch(100);
$userInstance->printSelfInfo();

其中fetch()方法和printSelfInfo()方法,都要封装在UserModel中,然而前者是model下面的方法,后者则是model具象出来的具体实例下的方法,二者如果都放在UserModel中,显然会出现下面这个尴尬的情况:

$userModel->printSelfInfo();

这个调用是允许呢?还是不允许呢?显然printSelfInfo()不应该被暴露给类、只应暴露给类实例。这个时候引入的Entity类就解决了上述的尴尬:Model层中的方法都是类方法,而Entity层中的方法都是暴露给实例的方法,也就是Entity相当于是一个实例类,当然官方翻译——他叫实体类。

每天学习一些新的知识,尽可能保持自己的学习动力。

Related Posts

小游戏(2)画一个小球并让它可以在画面中移动

因为之前实现的 Hello, world 程序是基于图形化窗口的,之所以仍然称为“Hello, world”只是一个编程约定俗成,其实更准确一些说应该是“基础运行窗口”,目的是将整个开发环境先搭建起来、跑起来。 既然是图形化的窗口,要做的事情自然不会是枯燥的文字输入输出,而是可以完成图形图像的绘制和显示,这就为完成一个简单的小游戏打下了良好的基础。 在这个“可绘图”的窗口中,通过使用矩形、圆形、矩形等基本的绘图指令,完成一些基本几何图形的绘制,这样就可以比较感性的感受到我们即将完成的游戏的外观样貌。虽然并不精美,也没有真正的游戏那么丰富的图像,但在初期进行“游戏原型”开发时,这是比较常用的方式。 这个视频就是在窗口中画一个圆形,并且每一次画面刷新的时候都调整一下这个圆形的位置,通过频繁的刷新、重绘,最终得到的整体效果就是小球好像在移动。 后面基于这个小球的绘制和移动的方法,将做出更多的几何图形,并且让他们按照规则进行各自的移动,彼此之间也会产生简单的碰撞检测和反弹规则。 需要注意两点: 1、对于真正的游戏,因为画面中存在着大量的图形元素,每一个图形元素都有自己的行动轨迹和运算过程,这将是对系统性能的极大挑战。所以在进行一个更为复杂的游戏开发时,并不能简单粗暴的按照当前的绘图、轨迹计算思路进行开发,而要有更多的考量。 例如对画面中的各个显示出来的图形进行可见性判断,如果它并不可见(被遮挡),那么就可以不进行运算或简化运算;对于某些复杂的碰撞或计算,要视图找出更高效的运算算法,以便确保游戏帧率得到保障;必要的时候,甚至会简化运算算法等等; 2、小球的行进过程、彼此的碰撞过程,实际上是对刚性运动物体进行模拟,我们自己实现整个物理规则,如果想实现的完善、正确,是比较复杂和困难的。如果真的要做游戏,更合理的做法是使用现成的物理引擎或游戏引擎进行游戏的开发。 当然现在这个“小游戏”并不是真的要实现一个成品游戏出来,而是我们计算机课程中的一道练习题,所以不允许使用现成的物理引擎进行开发,它实际上就是要考验我们自己是否有能力重新打造这些基本的方法和底层实现,所以没有偷懒的路径,只有自己一点点的将每一条物理规则实现出来。虽然我们实现的不一定完善、高效,但整体过程,还是要一步步走下来,才能得到一个比较满意的结果的。

試用Android Studio寫了一個小應用

一、做了個Android APP卻無法上架 大約半個月之前,我完成了對自己電腦的升級操作,新硬件很令人激動,無論是工作還是娛樂都十分順暢。於是我就想用這臺嶄新的電腦做些什麽有趣的事情。 之後大概花了兩天學習了一下Java語言和Android Studio的使用,然後便開始嘗試做一款小的APP出來。我原本預計要用30天的時間、6000行代碼左右,做出一個完成度比較高的應用。結果實際情況遠比自己設想的樂觀,只用了10天、2000行代碼,就實現了一個自我感覺良好的應用程式。 於是昨天又是一個心血來潮,花了25美元在Google Play注冊了一個開發者,想著將自己寫的APP發佈上架。結果在完成開發者的注冊之後才發現,如今的Google Play想上架一款新的應用非常難,門檻很高。 它有至少兩個我無法完成的門檻:真機驗證、封閉内測。 Google Play要求開發者完成真機驗證,雖然說幾乎所有的開發者都會有真實的Android手機,但是我的手機并沒有安裝GMS框架、也沒有Google Play應用、而且無法訪問Google網絡,這就導致我雖然有真機,卻無法完成Google Play要求的真機驗證。 第二點是封閉測試,這是更難以達到的。Google Play如今要求開發者在正式發佈應用之前,要有20人、進行14天的封閉測試。大概是說要有一個内部測試論壇用以討論、測試,連續14天的内測要求是活躍的、每天都有至少20人使用過這款應用。 就算對於一個非常有趣的應用產品,也幾乎沒有可能有人樂意連續20天使用。翻看一下自己的手機,如今除了微信、支付寶這樣的應用之外,還有哪一款應用是可能被用戶連續20天使用的呢?例如就算是每天坐公交車上下班、使用公交刷卡類APP,也不可能達到連續20天、天天使用。 同時我身邊也沒有那麽多的朋友、更沒有那麽多的朋友都能夠訪問Google Play應用商店或開發者社區,這就導致封閉内測對於我而言是肯定無法完成的。 大概看了一下網上的測試團隊,的確有一些專業團隊能夠承接測試工作,但是這些測試團隊幾乎都是按人、按次收費的,如果想完成Google Play的封閉測試,大約需要280人日,就算每一個人日我樂於付出100元的酬勞,這也是只是28000元的支出,才可能完成一次有效的封閉測試。 考慮到其中可能有些人臨時“放鴿子”、估計一次封閉測試支付要在3.5萬;如果一次封閉測試未能達到商家要求,再多做一次,那麽對於我的小應用而言,什麽都沒有做之前,就要先準備出至少7萬元用於完成“測試團隊的招聘”。這對於個人開發者而言,顯然是不可能、也無法接受的。 所以在看到上面真機驗證、封閉測試兩個門檻之後,我便後悔花了25美元開通Google Play的開發者賬號了。現在心情十分沮喪,不僅是因爲花了25美元的冤枉錢,更多的還是覺得對於個人開發者而言,沒有方向。 我現在基本放棄了將APP上架Google Play的計劃,轉而看一看有沒有其他的應用市場,對於個人開發者比較友好、或者索性就將自己做的應用直接打包成APK,裸包放在自己的網站上,供人下載、試用吧。 二、嘗試在Amazon Android…

微信开发工具禁用鼠标悬停提示功能

提示雖然方便,但總在不需要時彈出,很鬧心。而且說它方便只是相對而言,絕大多數情況下彈出來的提示只會擾亂視綫、影響操作,尤其在性能不高的電腦上更會引起界面卡頓,因而將它禁用才是更明智的做法。