什么是单一入口应用程序？
在解释什么是单一入口应用程序之前，我们先来看看传统的 web 应用程序。
news.PHP 显示新闻列表
news_edit.PHP 显示新闻编辑页面
这两个页面不但分别实现了两个功能，还成为了应用程序的两个入口。
news.PHP 显示新闻列表
news_edit.PHP 显示新闻编辑页面
这两个页面不但分别实现了两个功能，还成为了应用程序的两个入口。
那什么是入口啊？
打个比方，大家上 WC，都是男生进一个门，女生进一个门。这两个门就是 WC 的两个入口。
打个比方，大家上 WC，都是男生进一个门，女生进一个门。这两个门就是 WC 的两个入口。
呵呵，上面的例子应该很好理解吧。那稍微变换一下，单一入口的概念就很容易理解了。
现在我们是进一个公共 WC，不管男女都是从最外面的入口进入，交了钱以后才分别进两个门。那最外面的入口就是这个 WC 的单一入口。
现在我们是进一个公共 WC，不管男女都是从最外面的入口进入，交了钱以后才分别进两个门。那最外面的入口就是这个 WC 的单一入口。
所以单一入口的应用程序实际上就是说用一个文件处理所有的 HTTP 请求。例如不管是新闻列表功能还是新闻编辑功能，都是从浏览器访问 index.PHP 文件。这个 index.PHP 文件就是这个应用程序的单一入口。
很简单，我们访问 index.PHP 时跟上一个特定的参数就行了。例如 index.PHP?action=news 就是显示新闻列表，而 index.PHP?action=news_edit 就是新闻编辑。
上面的代码中，第一行是从 url 中取出 action 参数。如果没有提供 action 参数，就设置一个默认的 ‘index’ 作为参数。
第二行代码就是根据 $action 参数调用不同的代码文件，从而实现单一入口对应不同功能的效果。
第二行代码就是根据 $action 参数调用不同的代码文件，从而实现单一入口对应不同功能的效果。
单一入口应用程序的入口文件很复杂？
足够简单了吧？
当然了，在 index.PHP 里面写上一长串 switch case 绝对是拙劣的实现方式。但这纯粹是开发者自己的设计和实现问题，而不是单一入口应用程序这种设计思想的问题。
单一入口应用程序的设计思想
当web服务器（apache或者iis）收到一个http请求时，会解析该请求，确定要访问哪一个文件。例如
[url]http://www.xxx.com/news.php[/url] 的解析结果就是要求web服务器解析 news.PHP 文件，并返回结果给浏览器。现在看看单一入口应用程序的 index.PHP 文件，就会发现 index.PHP 实际上根据 url 参数进行了第二次解析。
完成这个解析的程序一般称为 Dispatcher（中文的准确翻译我也不知道），大概意思就是将不同的请求转发到不同的处理程序进行处理。
在单一入口应用程序中，index.PHP 和 web服务器一起构成了一个 Dispatcher，根据 http 请求和 url 参数来确定请求的处理程序。
了解了 Dispatcher 的概念后，我们可以发现前面提到的两行代码实际上就是一个最简单的 Dispatcher 实现：
诚然，对于一个安全、健壮的应用程序，Dispatcher 肯定不是上面那么简单。在调用实际代码前，还会加上各种判断、安全性检查等。例如判断 url 指定的功能是否可以访问以及 url 中包含了无效的参数。
单一入口应用程序的优势
这里我只拿安全性检查为例详细说明一下：
由于所有的 http 请求都由 index.PHP 接收，所以可以进行集中的安全性检查。如果不是单一入口，那么开发者就必须记得在每一个文件的开始加上安全性检查代码（当然，安全性检查代码可以写到另一个文件中，只需要include进来就可以了）。
但我想大家都是懒人，也许记性也不好，难免有忘记的时候。因此要记得在每一个文件前面都加上必要的include可不是件容易做到的事情。
由于所有的 http 请求都由 index.PHP 接收，所以可以进行集中的安全性检查。如果不是单一入口，那么开发者就必须记得在每一个文件的开始加上安全性检查代码（当然，安全性检查代码可以写到另一个文件中，只需要include进来就可以了）。
但我想大家都是懒人，也许记性也不好，难免有忘记的时候。因此要记得在每一个文件前面都加上必要的include可不是件容易做到的事情。
与安全性检查类似。在入口里，我们还可以对url参数和post进行必要的检查和特殊字符过滤、记录日志、访问统计等等各种可以集中处理的任务。
单一入口应用程序的缺点
要解决这个问题，可以采用 url 重写、PATHINFO 等方式。但我个人更推荐在前台页面不使用单一入口方式，而是保持多个文件入口。或者两者混用。例如新闻列表采用单独的 news.PHP 显示，而用户注册、发表信息等则采用单一入口。因为对于网站拥有者来说，新闻列表、新闻显示页面才是需要搜索引擎关注的高价值目标，而用户注册页面等交互性功能则根本没有收录的价值。
有朋友提到单一入口的应用程序会有很长一串参数，那么我们分析一下下面这个 url：
index.PHP?url=news&news_id=123&page=2&sort=title
如果改为直接访问 news.PHP，也只不过省掉了 url=news 这一个参数而已。
index.PHP?url=news&news_id=123&page=2&sort=title
如果改为直接访问 news.PHP，也只不过省掉了 url=news 这一个参数而已。
所以认为单一入口的应用程序 url 太复杂是没有道理的。
首先，对于应用程序的功能要做出一个合理的分解。例如后台的新闻栏目可能包含“添加新闻”、“编辑新闻”、“删除新闻”等多个功能。这时我们就可以将这一组逻辑上关联的功能组合到一个功能模块中，称为“新闻管理”模块。
按照上面的方法整理完应用程序的功能，我们就会得到多个功能模块，而每个模块又是由多个功能组成。（实际上，即便不是单一入口应用程序，功能的整理也是必须的步骤。）
按照上面的方法整理完应用程序的功能，我们就会得到多个功能模块，而每个模块又是由多个功能组成。（实际上，即便不是单一入口应用程序，功能的整理也是必须的步骤。）
1、每个功能模块一个子目录，目录里的每一个文件就是一个功能的实现代码。
这种方式的好处是每个功能的代码都互相隔离，非常便于多人协作。缺点是每个功能之间共享代码和数据不那么方便。例如新闻管理模块中的所有功能都需要一个“取出新闻栏目记录”的功能，那么采用这种多个独立文件的组织方式，“取出新闻栏目记录”就只能写在另一个文件中，然后由需要该功能的文件include进去。
这种方式的好处是每个功能的代码都互相隔离，非常便于多人协作。缺点是每个功能之间共享代码和数据不那么方便。例如新闻管理模块中的所有功能都需要一个“取出新闻栏目记录”的功能，那么采用这种多个独立文件的组织方式，“取出新闻栏目记录”就只能写在另一个文件中，然后由需要该功能的文件include进去。
2、每个模块一个文件，模块中的每个功能写成一个函数或者一个类方法。
好处不用多说了，非常便于共享代码和数据。缺点就是如果几个人同时改，容易发生冲突。不过借助版本控制软件和差异比较合并工具，冲突还是很容易解决的。
好处不用多说了，非常便于共享代码和数据。缺点就是如果几个人同时改，容易发生冲突。不过借助版本控制软件和差异比较合并工具，冲突还是很容易解决的。
调用首先就是要设计一个规则，然后让 index.PHP 根据这个规则来搜索和调用功能代码。就我自己来说，我总是使用 $_GET[’url’] 来指定要调用的功能模块，而 $_GET[’action’] 来指定该模块的特定功能。因此我的应用程序会使用如下的 url 地址：
index.PHP?url=news&action=edit
index.PHP?url=news&action=edit
觉得两个参数太多了？那可以使用 index.PHP?func=news.edit 这样的 url。只需要将 news.edit 拆开为 news 和 edit 就行了。
“嘿嘿，那我故意搞一个 index.PHP?url=news&action=xxx，看你的应用程序还能运行？”
很显然，这样的 url 只会使得 index.PHP 无法找到需要的功能代码，最后报告错误。但是这和你在浏览器中访问 newsxxx.PHP 这个并不存在的文件有什么本质区别呢？
很显然，这样的 url 只会使得 index.PHP 无法找到需要的功能代码，最后报告错误。但是这和你在浏览器中访问 newsxxx.PHP 这个并不存在的文件有什么本质区别呢？
在实际开发中，我倾向于将一些基本服务从应用程序中抽取出来，形成一个应用程序框架。这个框架通常会包含一个 Dispatcher、基本的数据库访问服务、模版引擎、常用的辅助功能等。由于有了一个框架，所以我可以更加让 Dispatcher 更加灵活。例如可以对某些功能模块应用权限检查，而另一些则不检查。
进一步了解单一入口应用程序
要深刻理解一个事物，自己尝试一下是最好的办法。
你可以选择自己实现一个 Dispatcher 以及相应的各种规则，或者选择一个现有的应用程序框架。但更好的方式还是首先尝试一下现有的框架，然后再自己尝试实现一个类似的。这样可以在最短的时间内获得最多的收获。
目前绝大多数 PHP 应用程序框架都是单一入口的，并采用了 MVC 模式（很遗憾，由于 MVC 实在太复杂，并且和单一入口应用程序也没有必然联系，所以我就不赘述了。感兴趣的朋友可以 google 一下相关资料）。
我个人推荐下面的框架：
FLEA1
[url]http://trac.dualface.com/trac/flea1/[/url]
嗯，我在做广告。因为这个框架是我做的。但我相信这个框架将是一个非常容易上手（就算不是最容易的）框架。
全中文的代码注释、简单的结构、精简的代码都是 FLEA1 框架的优势。
[url]http://trac.dualface.com/trac/flea1/[/url]
嗯，我在做广告。因为这个框架是我做的。但我相信这个框架将是一个非常容易上手（就算不是最容易的）框架。
全中文的代码注释、简单的结构、精简的代码都是 FLEA1 框架的优势。
CakePHP
[url]http://www.cakephp.org/[/url]
一个 Ruby on Rails 的 PHP 仿制品。具有出色的功能，但显然太过于复杂，而且缺乏中文资料是个很大的问题。
[url]http://www.cakephp.org/[/url]
一个 Ruby on Rails 的 PHP 仿制品。具有出色的功能，但显然太过于复杂，而且缺乏中文资料是个很大的问题。
其他
还有 Mojavi、Phing 等许多 PHP 框架，如果你精力充沛，可以去探索一下。
还有 Mojavi、Phing 等许多 PHP 框架，如果你精力充沛，可以去探索一下。
转自[
廖宇雷的部落格]
原文链接：https://www.f2er.com/javaschema/288214.html