facade

前几期阿牛 ger主讲了代码编码规范，整洁规范的代码有利于我们查询和再次开发，也方便我们检测与修复bug！这期，阿牛ger主要与大家分享数据库编码配置： 数据库配置 Niushop数据库配置方式与thinkphp相同，文件路径：config/database.php <?php use think\facade\Env; return [ // 默认使用的数据库连接配置 'default' => 'mysql', // 自定义时间查询规则 'time_query_rule' => [], // 自动写入时间戳字段 // true为自动识别类型 false关闭 // 字符串则明确指定时间字段类型 支持 int timestamp datetime date 'auto_timestamp' => true, // 时间字段取出后的默认时间格式 'datetime_format' => 'Y-m-d H:i:s', // 数据库连接配置信息 'connections' => [ 'mysql' => [ // 数据库类型 'type' => 'mysql', // 服务器地址 'hostname' => '******', // 数据库名 'database' => '****', // 用户名 'username' => '*****', // 密码 'password' => '*

一、MPP 架构 1、MPP架构的基础概念 MPP (Massively Parallel Processing)，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。 简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。 MPP 属于Shared Nothing，根据Shared 的不同，可以分为如下几种： Shared Everthting:一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer Shared Disk：各个处理单元使用自己的私有 CPU和Memory，共享磁盘系统。典型的代表Oracle Rac， 它是数据共享，可通过增加节点来提高并行处理的能力，扩展能力较好。其类似于SMP（对称多处理）模式，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能 。 Shared Nothing：各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP

参考博客《成功解决了我的问题，我是mySQL》： EF Core中执行Sql语句查询操作之FromSql，ExecuteSqlCommand，SqlQuery 代码如下： public static class DbContextExtensions { private static void CombineParams( ref DbCommand command, params object [] parameters) { if (parameters != null ) { foreach (SqlParameter parameter in parameters) { if (!parameter.ParameterName.Contains( " @ " )) parameter.ParameterName = $ " @{parameter.ParameterName} " ; command.Parameters.Add(parameter); } } } private static DbCommand CreateCommand(DatabaseFacade facade, string sql, out DbConnection dbConn, params object [] parameters) { DbConnection conn = facade

写在前面的话 我会先把源码直接给出来。博主本身也不是什么大牛，所以写的也不是什么很厉害的框架，只是一个很小很小的UI框架，给初学者一点入门的思路。 很多人在刚开始接触框架的时候都会有一种感觉：这NM什么DDX啊？！完全懵逼了有没有？！我还没开始写代码呢！怎么就已经有这么多代码要看啊？！还有大部分新人都会吐槽的事情：为什么要这么写啊？这玩意随便写个脚本挂上去不是分分钟实现功能吗？你这绕来绕去搞毛？这个主程是不是NT？！emmmmmmmmmmm…如果你知道主程怎么想的，你不就是主程了？ 所以，初次接触框架的话，可以抱怨，但是请尽快冷静下来，好好看代码。起码要以最快的速度会用这个框架，在慢慢去分析为什么框架要这么写。其实看完后你就会发现，主程写的框架实现一个功能确实很麻烦，但是你用起来的时候却非常方便，因为很多东西主程早早的就给你封装在框架里了，你只需要干一些不动脑子的体力活就实现了需求，爽就一个字！这就是为什么要使用框架，为什么主程要弯弯绕绕的实现功能。 好，如果你做好了思想准备，那么就先下载源码，读起来吧！这真的是一个很简单的UI框架，内容不多。读起来应该很容易。 UIFrame 提取码：gt4a 那接下来我们就开始吧！ 初次接触框架的读者可能会完全不知道从哪里下手阅读，那么博主就带着大家一起看看，这个框架主要是用来解决什么问题的。 脚本文件夹结构 这个框架有五个基本文件夹，分别是

前言 软件开发越来越复杂，对软件设计的要求也越来越高，而软件设计和架构的入门功夫就是深入理解和掌握设计模式。因此，设计模式的重要性不言而喻。 很多朋友认识到了设计模式的重要性，也看了很多的书籍和资料，但是，常听到这样的抱怨:“ 设计模式的书我看了不少，觉得都看懂了，就是不知道在实际开发中怎么运用这些设计模式”，从而认为设计模式是"看上去很美的花拳绣腿”。 其实不然，造成这种情况的原因就在于:这些朋友对设计模式的理解不到位，自己感觉懂了，其实还差很远，并没有“真正”理解和掌握设计模式。 本文就针对这种情况，让大家真正理解和掌握23种设计模式，并且能够灵活运用，希望大家能够喜欢！！！ 目录 主要内容 第1章设计模式基础， 什么是模式？从字面上理解，模，就是模型、模板的意思:式，就是方式、方法的意思。综合起来，所谓模式就是:可以作为模型或模板的方式或方法。再简单点说就是可以用来作为样板的方式或方法，类似于大家所熟悉的范例。 按照上面的理解，设计模式指的就是设计方面的模板，也即设计方面的方式或方法。 设计模式:是指在软件开发中，经过验证的，用于解决在特定环境下、重复出现的、特定问题的解决方案。 第2章简单工厂，简单工厂不是一个标准的设计模式，但是它实在是太常用了，简单而又神奇，所以需要好好掌握它，就当是学习设计模式的热身运动吧。为了保持一致性，我们尽量按照学习其他模式的步骤来进行学习。

假设我们设置了一个路由参数： /** * 定义路由参数名称分别为： param1，param2 */ Route::get('/{param1}/{param2}', 'TestController @index '); 现在我们访问 http://test.dev/1/2 在 TestController 中： /** * 路由参数获取方法 * * @param Illuminate\Http\Request $request 依赖注入 Request 实例，放在参数中什么位置都可以自动加载 * @param mixed $arg2 要获取的路由参数 * @param mixed $arg1 要获取的路由参数 */ public function index(Request $request, $arg2, $arg1) { /** * 方法一：按照 URL 中路由参数先后顺序来获取 * 注意：此种方式有个小坑，获取的值只与顺序有关，与名称无关 */ echo $arg2; //结果为 1 ，因为 $arg2 在第一位，获取的是第一个路由参数 param1 的值 echo $arg1; //结果为 2 ，因为 $arg1 在第二位，获取的是第二个路由参数 param2 的值 /** * 方法二：按照路由参数名称来获取 * 注意：此处名称是 Route 中定义的参数名

简单描述 外观模式（Facade pattern），为子系统中的一组接口提供一个统一的高层接口，使得子系统更容易使用。 外观模式又称为门面模式，它是一种对象结构型模式，遵循 迪米特法则 ，又称最少知道原则。 模式动机 现代的软件系统都非常复杂，尽管我们已经想尽一切方法将其“分而治之”，把一个系统划分为好几个较小的子系统了，但是仍然可能会存在这样的问题：子系统内有非常多的类，客户端往往需要和许多对象打交道之后 才能完成想要完成的功能。 在我们的生活中医院就是这样的。一般的医院都会分为挂号、门诊、化验、收费、取药等。看病的病人要想治好自己的病（相当于一个客户端想要实现自己的功能）就要和医院的各个部门打交道。首先，病人需要挂号，然后门诊，如果医生要求化验的话，病人就要去化验，然后再回到门诊室，最后拿药，经过一系列复杂的过程后才能完成看病的过程。如下图所示： 解决方案： 解决这种不便的方式就是引入外观模式。如果我们在医院设立一个接待员的话，病人只负责和接待员接触，由接待员负责与医院的各个部门打交道，让接待员完全帮助我们实现“看病”各个操作，如下图所示： 模式结构图 外观模式的基本组成： 外观角色 Facade：模式的核心，被客户 Client 调用，知道各个子系统的概念。根据客户角色的需求定制功能组合。 子系统角色 SubSystem：实现子系统的功能。 客户角色 Client：调用