目录
 
侵入式（引入或继承了别的包或框架）
非侵入式（没有依赖，自主研发）

 
侵入式（引入或继承了别的包或框架）
 
从字面意思理解，就是你的代码里已经嵌入了别的代码，这些代码可能是你引入过的框架，也可能是你通过接口继承得来的（比如：java中的继承），这样你就可以拥有侵入代码的一些功能。所以我们就称这段代码是侵入式代码。非要说侵入式代码的优点：通过侵入代码与你的代码结合可以更好的利用侵入代码提供给的功能。缺点：框架外代码就不能使用了，不利于代码复用。依赖太多重构代码太痛苦了。
 
非侵入式（没有依赖，自主研发）
 
正好与侵入式相反，你的代码没有引入别的包或框架，完完全全是自主开发。比如golang中的结构体中的字段组合，这是非侵入式的，我完完全全可以其中某个字段的方法集合，或者我可以通过实现自己的方法集合从而达到剥离依赖关系的目的。优点：代码可复用，方便移植。非侵入式也体现了代码的设计原则：高内聚，低耦合

java框架就是一些类和接口的集合，通过这些类和接口协调来完成一系列的程序实现。JAVA框架可以分为三层：表示层，业务层和物理层。框架又叫做开发中的半成品，它不能提供整个WEB应用程序的所有东西，但是有了框架，我们就可以集中精力进行业务逻辑的开发而不用去关心它的技术实现以及一些辅助的业务逻辑。大家熟知的Structs和Spring就是表示层和业务层框架的强力代表，新出来的JFinal 是基于Java 语言的极速 web 开发框架，其核心设计目标是开发迅速、代码量少、学习简单、功能强大、轻量级、易扩展、Restful。在拥有Java语言所有优势的同时再拥有ruby、python等动态语言的开发效率。
 
 E良师益友有相关的极速开发课程，有兴趣可以看看：http://www.elsyy.com/course/c-26-1-1
 

项目github地址：bitcarmanlee easy-algorithm-interview-and-practice
 欢迎大家star，留言，一起学习进步
 
1.先名词解释吧：
 
DAO = Data Access Object = 数据存取对象
 
Service = 服务
 
Controller = 控制器
 
Util = 工具
 
Model = 模型
 
首先，一个代码是不是有完善的结构，和是不是有上面这些东西没有什么关系，只是通常来说，我们做一个大项目会把项目分解成很多不不同的模块（Module），然后根据用途和角色，我们对这些模块有一个通用的命名规则，这也就是上面这些英文单词的来历。所以，请一定记住，项目中是否包含这些模块或者单词，和你的项目结构是否完善一毛钱关系没有。但是当你的项目结构相对完善的时候，你会发现有这样一些角色的存在。
 
接下来一个个的来详细讨论一下这个东西是如何出现的：
 
2.DAO
 
DAO，数据存取对象。通常我们会遇到很多要和数据库打交道的场景，如果为每一个场景都去写一些SQL语句，会让我们代码变得很奇怪，我们希望我们的代码比较干净整洁，那么一个很容易想到的方案就是把数据库封装一下，让我们和数据库的交道看起来比较像和一个对象打交道。这个对象通常就是DAO，当我们操作这个对象的时候，这个对象会自动的产生SQL语句来和数据库打交道，而我们只需要和DAO打交道就可以了。
 当然，从本质上来说，DAO并不需要和数据库有什么必然的联系，DAO只是数据存取对象的缩写，所以只要是把数据持久化包装成一个对象的访问（读写），这种对象都可以被称之为DAO，譬如，用JSON格式存到硬盘上。
 
3.Service
 
Service，我们有时候会需要一些相对独立，与业务系统没啥关系的功能。但不是所有的功能都可以做成一个服务，服务是一个相对独立的功能模块，完成一些指定的工作，这些工作高度抽象和通用。一个典型的服务像是数据库服务、缓存服务、文件存储服务、身份验证服务、消息队列服务等。
 关系型数据库服务可以视为是一个接收SQL语句并给出一个查询结果的服务，我们不必关心服务内部具体是如何处理问题的，我们只需要关注服务给出的接口。
 并不是所有的模块都适合做成服务，一个服务首先最重要的是独立性，这个服务必须可以独立的完成指定的工作。复杂的服务可能依赖于一个或者多个更基础的服务，但是服务通常不应当依赖于任何具体的业务代码，服务必须具有高度的抽象性。关系型数据库服务就具有高度的抽象性，事实上只要我们撰写标准的SQL，不论后面是MySQL、SQL Server还是Oracle，他们都会呈现出几乎完全相同的行为。
 一个更为简单的服务像是缓存服务，我们把一坨数据放进去，在一段时间内可以快速的获取这坨数据，在一段时间后数据就会消失。
 当你的代码需要一个高度抽象高度标准化的功能，而这个功能又不能简单的实现，或者这个功能需要很多资源的配合，例如缓存服务需要内存资源，而数据库服务通常需要磁盘资源，身份验证服务通常需要数据库服务支持。这个时候就可以考虑将这个功能模块做成一个服务。
 服务作为基础的部件，我们通常会要求它能够应付各种各样的情况，一个优质的服务通常会有非常高的可用性，因为我们的系统可能会依赖于各种各样的服务，而整个系统的可用性将不可能比其中任何一个服务的可用性更高。
 所以服务的特征：抽象、独立、稳定。
 
评论中提到Java项目中的Service通常是指Business Service，这里也简单说说。
 很多时候，我们发现服务的特征对于我们开发一个大型项目的时候很有帮助。就拿独立性来说，关系型数据库服务如SQL Server可以独立发售，独立安装和部署。它可以自行测试自己的接口，如果都达到了预期的效果，并且能够应付各种情况，这个服务就可以作为一个产品独立的出售给我们安装。这意味着关系型数据库服务并不需要配合我们的业务系统一起进行测试和调试，或者作出什么变更。
 在完成一个大型的业务系统时，我们发现一些子模块或者子系统也可以像服务一样独立的部署和测试。例如会员系统、支付系统、订单系统等等，他们的业务逻辑可能非常复杂，但是逻辑相对独立，并且高度内聚。如果我们将这些系统分别独立的测试和部署，就可以大大的降低我们的测试、部署和运维的成本。
 这些可以独自完成某一方面业务功能，高度内聚，可以独立部署测试的模块，我们可以称之为Business Service，业务服务。它同样具有服务的特征，抽象、独立和稳定。一个会员系统内部的逻辑可能非常复杂（积分规则，分级规则，风险控制，行为数据），但是在其外部，会员的概念可以非常简单。
 
4.Util
 
Util，Util通常来说是我们找不到合适的名字的时候的选择，Util就是工具，在做项目的时候我们总会遇到一些奇奇怪怪的小功能或者重复的代码需要提取。像是URL编码或者解码（当然这个类库通常会提供，不过就以 .NET Framework 为例，提供这个方法的类型名称叫做HttpUtility），或是自创的加密签名算法等等。
 
5.Model
 
Model，模型，通常来讲，我们会把模型和另一个东西放在一起来说：View，视图。
 
模型通常认为是视图的内核，何谓之视图？我们正在与之交互的知乎网站的界面就是视图，而模型是指他的内核：数据。
 
知乎的数据是问题和答案，问题分为标题和描述，答案有内容和作者以及各种状态。知乎有很多个UI，例如移动页面，普通PC页面，手机APP，以及改版前的旧界面，这些被称作不同的视图。而所有这些形态迥异的视图，其内核都是一样的，这个内核我们就称之为模型（Model）。
 
将Model和View的概念拆分开来，有助于我们关注不同的方面，也可以更有效的分工。有些工程师更关注于内核也就是模型，通常来说，他们被称之为后端工程师。有些工程师更关注于用户界面的交互和展示，通常来说，他们被称之为前端工程师。
 
原文链接：
 https://www.zhihu.com/question/58410621/answer/157049250

回答一：

广义上讲：
轻量级与重量级是一个相对的概念，主要是对应用框架使用方便性和所提供服务特性等方面做比较的。   
  比方说EJB就是一个重量级的框架，因为它对所编写的代码有限制，同时它也提供能分布式等复杂的  功能。   
  相比之下，Spring就是轻量级框架，因为它需要的只是普通的Java对象，它所提供的也只是足够中小应用使用的功能。   
  但是，随着Spring的发展，它也所具有的功能也越来越强大，而EJB的使用也在变得简单，所以这随着技术的发展，这个概率也需要更新。毕竟它的出现是为了和使用复杂的框架做区别，那么当当家都在不断吸收对方长处的时候这个界线就没有那么明显了。   

狭义上讲：
重量组件一般支持线程安全而轻量不支持。
JDK GUI里面的awt包 为重量级，swing包尾轻量级。
集合类List、Map、Set为轻量级，Vector、Hashtable为重量级
 

 
 

 
 
回答二：
 
就是看加载的资源 
 
 
spring也不能说是轻量级的
 
EJB默认在应用启动的时候把所有资源和服务都加载进来，而spring则是你定制服务 需要什么开什么 
 
 
如果把spring的所有服务都用上的话 可以认为你是用了一个重量级的框架 实质还是看框架所需要的系统资源大小 
 

 
 
还有说开发侧重点不同的....
 
不觉得不用去纠结字面意义，只要知道什么情况使用哪种框架就可以了、