为什么PHP不适合计算密集型业务

回答这个问题,我们来了解一下为什么说PHP慢?

PHP的慢是相对于C/C++级别的语言来说,事实上,PHP语言最初的设计,就不是用来解决计算密集型的应用场景。我们可以这样粗略理解为,PHP为了提升开发效率,而牺牲了执行效率。

我们知道PHP一个很大的特点,就是弱类型特性,也就是说,我可以随意定义一个变量,然后给它随意赋值为各种类型的数据。以一个int整型数字为例子,在C语言中:

但是,如果是PHP定义了一个同样的变量,实际对应的存储结构则是:

 

Continue reading “为什么PHP不适合计算密集型业务”

Ubuntu Server 14.04 LTS中安装最新版的PHP7.1

由于PHP7.x相对于PHP5.x在性能上有数倍的提升,因此我也趁此将服务器的PHP配置升级一下。

Ubuntu Server 14.04 LTS官方安装包源中默认的是稳定版的PHP5.x系列,如果想要安装最新的PHP7.x需要使用第三方安装包源。

我们这里使用Ubuntu的ppa第三方源ondrej/php,依次执行以下命令即可:

Continue reading “Ubuntu Server 14.04 LTS中安装最新版的PHP7.1”

在PHPStorm中使用Lge_CodeSniffer(Linux+Windows)

在PHPStorm中使用Lge_CodeSniffer其实相当于在PHPStorm中启用PHP_CodeSniffer检测,并设置检测标准为Lge即可。

在开始本篇文章之前,请先在本地安装好 PHP_CodeSniffer + Lge_CodeSniffer,请参考:

1、Windows:Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Windows)

2、Linux:Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Linux)

Continue reading “在PHPStorm中使用Lge_CodeSniffer(Linux+Windows)”

Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Linux)

Lge_CodeSniffer是基于PHP_CodeSniffer的自定义编码规范检测脚本,编码规范基于PSR-2,对于少部分编写风格做了自定义调整,PSR-2 规范请参考:http://www.php-fig.org/psr/psr-2/,自定义Lge编码规范请参考PDF编码规范文件

本文是在Linux下配置PHP_CodeSniffer+Lge_CodeSniffer代码检测工具的介绍,如果是Windows下的配置,请参考我的另外一篇文章:Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Windows)Continue reading “Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Linux)”

PHP设计模式 – 服务定位器模式(Service Locator)

1、模式定义

当系统中的组件需要调用某一服务来完成特定的任务时,通常最简单的做法是使用 new 关键字来创建该服务的实例,或者通过工厂模式来解耦该组件与服务的具体实现部分,以便通过配置信息等更为灵活的方式获得该服务的实例。然而,这些做法都有着各自的弊端:

1)、在组件中直接维护对服务实例的引用,会造成组件与服务之间的关联依赖,当需要替换服务的具体实现时,不得不修改组件中调用服务的部分并重新编译解决方案;即使采用工厂模式来根据配置信息动态地获得服务的实例,也无法针对不同的服务类型向组件提供一个管理服务实例的中心位置;

2)、由于组件与服务之间的这种关联依赖,使得项目的开发过程受到约束。在实际项目中,开发过程往往是并行的,但又不是完全同步的,比如组件的开发跟其所需要的服务的开发同时进行,但很有可能当组件需要调用服务时,服务却还没完成开发和单体测试。遇到这种问题时,通常会将组件调用服务的部分暂时空缺,待到服务完成开发和单体测试之后,将其集成到组件的代码中。但这种做法不仅费时,而且增大了出错的风险;

3)、针对组件的单体测试变得复杂。每当对组件进行单体测试时,不得不为其配置并运行所需要的服务,而无法使用Service Stub来解决组件与服务之间的依赖;

4)、在组件中可能存在多个地方需要引用服务的实例,在这种情况下,直接创建服务实例的代码会散布到整个程序中,造成一段程序存在多个副本,大大增加维护和排错成本;

5)、当组件需要调用多个服务时,不同服务初始化各自实例的方式又可能存在差异。开发人员不得不了解所有服务初始化的API,以便在程序中能够正确地使用这些服务;

6)、某些服务的初始化过程需要耗费大量资源,因此多次重复地初始化服务会大大增加系统的资源占用和性能损耗。程序中需要有一个管理服务初始化过程的机制,在统一初始化接口的同时,还需要为程序提供部分缓存功能。

要解决以上问题,我们可以在应用程序中引入服务定位器(Service Locator)模式。

服务定位器(Service Locator)模式是一种企业级应用程序体系结构模式,它能够为应用程序中服务的创建和初始化提供一个中心位置,并解决了上文中所提到的各种设计和开发问题。

服务定位器模式和依赖注入模式都是控制反转(IoC)模式的实现。我们在服务定位器中注册给定接口的服务实例,然后通过接口获取服务并在应用代码中使用而不需要关心其具体实现。我们可以在启动时配置并注入服务提供者。

如果你了解 Laravel 框架,你对这一流程会很熟悉,没错,这就是 Laravel 框架的核心机制,我们在服务提供者中绑定接口及其实现,将服务实例注册到服务容器中,然后在使用时可以通过依赖注入或者通过服务接口/别名获取服务实例的方式调用服务。 Continue reading “PHP设计模式 – 服务定位器模式(Service Locator)”

PHP设计模式 – 依赖注入模式(Dependency Injection)

1、模式定义

依赖注入(Dependency Injection)是控制反转(Inversion of Control)的一种实现方式。

我们先来看看什么是控制反转。

当调用者需要被调用者的协助时,在传统的程序设计过程中,通常由调用者来创建被调用者的实例,但在这里,创建被调用者的工作不再由调用者来完成,而是将被调用者的创建移到调用者的外部,从而反转被调用者的创建,消除了调用者对被调用者创建的控制,因此称为控制反转。

要实现控制反转,通常的解决方案是将创建被调用者实例的工作交由 IoC 容器来完成,然后在调用者中注入被调用者(通过构造器/方法注入实现),这样我们就实现了调用者与被调用者的解耦,该过程被称为依赖注入。

依赖注入不是目的,它是一系列工具和手段,最终的目的是帮助我们开发出松散耦合(loose coupled)、可维护、可测试的代码和程序。这条原则的做法是大家熟知的面向接口,或者说是面向抽象编程。 Continue reading “PHP设计模式 – 依赖注入模式(Dependency Injection)”

Laravel 服务容器 – 控制反转(IoC)和依赖注入(DI)

容器,字面上理解就是装东西的东西。常见的变量、对象属性等都可以算是容器。一个容器能够装什么,全部取决于你对该容器的定义。当然,有这样一种容器,它存放的不是文本、数值,而是对象、对象的描述(类、接口)或者是提供对象的回调,通过这种容器,我们得以实现许多高级的功能,其中最常提到的,就是 “解耦” 、“依赖注入(DI)”。本文就从这里开始。

Continue reading “Laravel 服务容器 – 控制反转(IoC)和依赖注入(DI)”

Lge的数据校验功能

Lge的数据校验功能满足绝大多数业务场景的需要,支持对同一字段多规则校验,并允许自定义错误信息。

以下是框架支持的36种校验规则:

Continue reading “Lge的数据校验功能”

Lge的数据库操作

Lge的数据库组件是框架的核心组件之一,该数据库组件的特点有:

1、底层基于PDO扩展,支持所有主流的数据库管理系统,并通过MySQL、PostgreSQL、Oracle、SQLServer及SQLite的测试使用;

2、数据库底层天然支持主从读写分离,只需通过配置文件简单配置项即可支持对主从数据库集群的操作;

3、数据库单例对象管理,在同一请求处理进程中,多次数据库操作只会保留同一份数据库链接;

4、数据库底层统一采用SQL预处理操作,防止SQL注入,增强数据库安全性;

5、方便灵活的CURD操作方法,单表封装对象;

6、支持数据库超时重连机制及数据表前缀;

Continue reading “Lge的数据库操作”