看到你修改了问题，并对问题做了详细描述，那么，我来好好的回答这个问题，其实整套分层的意义很简单，不外乎围绕的是根本原因：

程序 = 数据结构 + 算法

所有的层的拆分都是围绕着数据结构和算法来整理的，分层的根本意义也是为了让逻辑更加清晰易懂，首先，来看看你摘自TP官网的定义：

ThinkPHP支持模型的分层 ，除了Model层之外，我们可以项目的需要设计和创建其他的模型层。

通常情况下，不同的分层模型仍然是继承系统的thinkModel类或其子类，所以，其基本操作和Model类的操作是一致的。
例如在index模块的设计中需要区分数据层、逻辑层、服务层等不同的模型层，我们可以在模块目录下面创建model、logic和service目录，把对用户表的所有模型操作分成三层

• 数据层：app\index\model\User 用于定义数据相关的自动验证和自动完成和数据存取接口
• 逻辑层：app\index\logic\User 用于定义用户相关的业务逻辑
• 服务层：app\index\service\User 用于定义用户相关的服务接口等

其实他官方的解释已经挺清楚了，但是如果你没有接触复杂的业务可能不太理解这三层的定义，我逐个就我遇到的一些业务问题来做详细的讲解：

数据层

数据层在这里其实指的是数据库表的数据，一般来说数据层会包含一整套相对于数据表的映射，这一套映射主要的是基本的字段名称和数据类型的映射，比如数据表order里有一个字段叫做order_sn并且是16位的字符串类型，那么在数据层模型里可以定义这套映射，而这套映射的根本目的其实也是为了实现程序做最基础的数据存储类型的验证，当然了，这套基本的自动验证也是依赖于框架来实现的。

然后就是自定义的一些自动验证了，比如数据类型是否是url，对数据进行安全过滤等等；也就是说，这一层完成数据的存储处理。当然也可以完成一些查询处理，如时间格式化等等。

逻辑层

逻辑层，从程序方面来思考，应该叫做算法层，这一层处理具体的一些数据的业务逻辑，或者做事务性的一次性存储多个数据表数据等，这一层最好也把大的复杂逻辑尽量拆分成小的业务逻辑，减少业务的耦合性。主要做的还是与具体业务相关的业务逻辑。

服务层

服务层一般来说是直接与控制器打交道的，提供给控制器进行调用的一层，这一层可以让多个控制器共用，而服务层所调用的数据业务层应该是逻辑层。

从以上三个方面来看，数据层可以说是程序的数据，而逻辑层是程序的算法；当然这个角度又是从宏观角度来看待的。而服务层又能把各个逻辑关联起来，起到很好的整体性，能提供给应用上层调用，减少代码的冗余，可以更好的复用。

另外我看到有人回答说用java来写，我觉得这就是语言论了，程序的根本就是思想，老是想着语言相关性，不知道意义何在，我更趋向于语言无关性，借鉴不同的语言特性思想，来表现不同的业务逻辑。

服务、逻辑分层，本质是为了解决控制器或者模型代码臃肿肥大而出现的（把调用接口跟数据处理都写在一起），但是我们可以使用trait跟基类来减少重复代码，提高复用，而不需要服务、逻辑分层，MVC嘛，越简单粗暴越好

可以研究下zend框架或者看下某些大神用php写的二次开发项目怎么写的

很多人一般控制器调用模型，然后没了。如果分层的话，就是控制器调用服务或者逻辑，服务或者逻辑调用模型。
数据层就是model模型，一般只做数据表的定义，自动验证，基本不写方法的，方法主要写到逻辑和服务层，通过D方法来操作表。
逻辑层和服务层：有关数据库的增删改查、数据的处理。
我是这么理解的，业务复杂且涉及调用多个子方法或者操作多张表的就写到逻辑里面，其余像简单的数据处理、组装、封装、单表操作，这些写到服务层。

分层的意义：

1.解耦
2.职责分明
3.提高代码复用率
4.利于维护
5.提高代码的健壮性

给个层的职责：

控制器(controller)： 只 负责调度 service以及view，提供对外路由访问

模型(model)： 只负责对数据表执行CURD操作,不做任何业务处理

服务层(service): 只调用model,只做业务处理。

逻辑层其实完全可以省略了,以上的3个就足以。

控制器(controller)： 只 负责调度 service以及view，提供对外路由访问

模型(model)： 只负责对数据表执行CURD操作,不做任何业务处理

服务层(service): 只调用model,只做业务处理。

至于其他楼上说的就很好

上面做了很详细的解释了,按我的话说就是MVC差不多,V带表视图文件,M模型一般在里面做验证之类的,C就是控制器了!

刚接触，来学习的