framework/├── public/│ └── index.php← 入口文件├── src/ ← 项目源码│ └── controller/← 掌握器目录│ └── App.php← 核心解析类├── vendor/ ← Composer安装的第三方库│ └── autoload.php└── composer.json要点nginx
由于框架利用了单一入口，任意要求都会指向index.php文件，以是只须要这么配置：
location / {try_files $uri $uri/ /index.php?$query_string;}autoload
框架中的自动加载利用的是PSR-4的规范，大致事理便是通过文件系统目录构造与PHP的命名空间逐一映射起来，即命名空间指向文件所在目录，详细PSR规范可以看这篇文章。以是框架的composer.json文件中我们这样定义：
"autoload": { "psr-4": { "app\": "src/" }}
app开头的命名空间指向src目录。
既然是入口，那只管即便不要做过多限定，让入口变得很臃肿、繁芜，只要引入必要的依赖和配置就行，其他事情就交给别人去做就好了，详细如下：
header("Content-type: text/html; charset=utf-8");date_default_timezone_set("Asia/Shanghai");require "../vendor/autoload.php";define('ROOT', __DIR__ . '/../src');$app = new \app\App();$app->run();
index.php内容就很大略，没啥好说的，紧张解析操作和掌握器的分发交给了\app\App处理。
掌握器这个大略的框架是没有单独的路由配置文件的，熟习laravel的都知道，写业务逻辑之前须要先在routes.php文件中定义路由，而这个框架直接是通过要求路径对应到指定的掌握器及方法，比如要求/user/info，掌握器便是User，吸收方法便是Info，看下怎么解析的：
// App.phppublic function parse() {$uri = $this->param('REQUEST_URI', 'server');$p = strpos($uri, '?');if ($p > 0) {$uri = substr($uri, 0, $p);}@list($_, $controller, $action) = @explode('/', $uri);if (empty($controller)) { $controller = 'index'; }if (empty($action)) {$action = 'default';}if ($controller && $action) {$c = '\app\controller\\' . ucfirst($controller);$a = 'Action' . ucfirst($action);if (is_callable(array($c, $a))) {$this->controllerName = $c;$this->actionName = $a;return true;}}}public function run() {$this->parse();if ($this->controllerName && $this->actionName) {$c = $this->controllerName;$a = $this->actionName;$ins = new $c();$ins->app = $this;do {$res = $ins->before() ;if ($res === false) break;$res = $ins->$a();if ($res === false) break;$ins->after();} while(false);}}
上面便是大致的解析流程，解析完成后会实例化对应的调用方法，我们看下掌握器是怎么写的：
namespace app\controller;class User extends Base{ public function ActionInfo() { $this->setResponse('aa', 123); $this->setResponse('bb', 'hello'); }}
这里，可以看到掌握器和方法有点像两级目录，掌握器属于一级，对应的方法属于二级目录，大略清晰，但是不能处理繁芜路由。
数据库公司内部利用的是自研的一套数据模型，便是封装的一个抽象数据层，包括了redis，mysql等，如果要利用Eloquent等其他比较盛行的ORM，这里可以合营composer autoload利用。
缺陷没有统一的路由配置文件，每个路由须要人工记住有哪些掌握器和方法。
一个路由只能针对一个要求利用，拿上面的/user/info来说，get、post要求都会发送到同一个处理方法上，这就变得很耦合，而且也不符合不同要求方法本身的目的，但可以建新的路由来办理，可也会增加路由数量造成掩护的包袱。
短缺一套模版引擎。
总结比较于市情上成熟的框架，这个框架可谓相称的简陋，可以说是非常原始了，没有任何高大上的技能，比如依赖注入、做事容器、做事供应者等。我认为框架便是一套约定好的代码编写风格以及大量工具类的凑集，学会利用框架便是按照这套风格写掌握器，什么地方放配置文件，节制工具类的利用，毕竟大部分情形都是处理CURD和编写业务逻辑，利用框架会大幅度提高开拓效率。以是在选择框架时没必要在意利用了什么技能，反而更该当在意框架的效率/性能以及周围的生态。当然这也不妨碍我们自己造轮子 ^^
