1、mvc架构
MVC是一种设计模式(Design pattern),也就是一种解决问题的方法和思路, 是上世纪80年代提出的,到现在已经颇有历史了。 MVC的意义在于指导开发者将数据与表现解耦,提高代码,特别是模型部分代码的复用性。MVC是模型(Model)、视图(View)、控制器(Controller)3个单词的缩写。
具体参看:
https://www.cnblogs.com/zuoshoushizi/p/8324672.html
2、目前的技术在开发中存在的问题(why )
1: 一个项目就是一个工程
如果项目非常大,就不适合继续 使用package来划分 模块,最好一个模块对应一个工程,利于分工协作。
借助于MAVEN就可以就一个项目拆分成多个工程。
2:项目中需要的JAR包必须手动复制,粘贴,到WEB-INF/lib目录下
带来的问题:同样的JAR包文件重复出现在不同的项目中,一方面浪费存储空间,另外也让工程比较臃肿。
借助Maven,可以将jar包仅仅保存在“仓库”中,有需要使用工程“引用”这个文件接口,并不需要真的把JAR包复制过来
3:JAR包需要别人替我们准备好,或者到官网下载
不同技术的官司网提供的JAR包下载的形式五花八门 有些技术的官司网就是通过Maven或SVN等专门的工具来下载
如果是以不规范的方式下载的JAR包,那么其中的内容很可能也是不规范的。 借助于Maven可以以一种规范的方式下载JAR包,因为所有知名框架或者第三方工具的JAR包以及按照统一的规范存放在了Maven的中央仓库中, 以规范的方式下载的JAR包,内容也是可靠的
Tips:"统一规范" 不仅是对IP开发领域非常重要,对于整个人类社会都是非常重要的。
4:一个jar包依赖的其他JAR包
FileUpload组件 依赖于IO组件,commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar
如何 所有jar包之间的依赖关系都需要程序员自己非常清楚的了解,那么就会极大的增加学习成功
Maven会自动将被依赖的JAR包导入进来。
3、Maven是什么(what)
1 Maven是一款服务于Javag平台的自动化构建工具
make-->Ant -->Maven -->Gradle
2 概念:以JAVA源文件,框架配置文件,JSP,HTML图片等为源材料去“生产”一个可以运行的项目的过程
编译,部署,搭建
3 编译:Java源文件(User.java)-->编译-->Class字节码文件,交给JVM执行
4:部署:一个BS项目最终运行的并不是并态Web工程本身,而是这个动态Web工程“编译的结果”
开发过程中,所有的路径或者配置文件中配置的类路径等都是以编译结果的目录结构为标准的。
Tips:运行时环境:是一组JAR包的引用,并没有把JAR包本身复制到工程中,所以并不是目录
构建过程中的各个环节
【1】清理:将以前编译得到的旧的class字节码文件删除,为下一次编译做准备
【2】编译:将JAVA源程序编译成class字节码文件
【3】测试:自动测试,自动junit程序
【4】报告:测试程序执行的结果
【5】打包:动态WEB工程打WAR包,JAVA工程打JAR包
【6】安装:Maven特定的概念--将打包得到的文件复制到“仓库”中的指定位置
【7】部署:将动太WEB工程生成的WAR包复制 到Servlet容器的指定目录下,使其可以运行
4、自动化购建。
1:检查%JAVA_HOME%环境变量
echo %java_home%
2:解压Maven核心程序的压缩包,放在一个非中文无空格的路径下
3:配置Maven相关的环境变量
【1】MAVEN_HOME或者M2_HOME
【2】PATH
4:执行mvn -v命令查看。
5、Maven的核心概念
1:约定的目录结构
2:POM
3:坐标
4: 依赖
5:仓库
6:生命周期/插件/目标
7: 继承
8:聚合
6、第一个Maven工程
1: 创建约定的目录结构。
[1]【根目录】:工程名
[2]【src】:源码
[3]【pom.xml】Maven工程的核心配置文件
[4]【main】存入主程序
[5]【test】存放测试程序
[6] [java] :存放JAVA源文件
[7] [resources]:存放框架或其它工具配置文件
2:为什么要遵守约定的目录结构
【1】Maven要负责我们这个项目的自动化构建,以编译为例,Maven要想自动进行编译,那么它必须知道java源文件保存在哪里。
【2】如果我们自己自定义的东西想要让框架或工具知道
a:以配置的形式告诉框架
b: 遵守框架内部已经存在的约定
约定>配置>编码,
7、常用Maven命令
1:注意:执行与构建过程相关的Maven命令,必须进入pom.xml所在的目录
2:常命令
[1]mvn clean:清理
[2]mvn compile:编译
[3]mvn test-compile:编译测试程序
[4]mvn test:执行测试
[5]mvn package:打包
[6] mvn install:安装
[7]mvn site:生成站点
8、 关于联网的问题
1:Maven的核心程序中仅仅定义了抽象的生命周期,但是具体的工作必须由特定的插件来完成。而插件本身并不包含在Maven核心程序中
2:当我们执行的Maven偏偏需要到某些插件时,Maven核心程序会首先到本地仓库中查找
3:本地仓库的默认位置,系统中当前用户的家目录(C:\Users\登陆用户名)\.m2\repository
4:Maven核心程序如果在本地仓库中找不到需要的插件,那么它会自动连接外网,到中央仓库下载。
5:如果此时无法连接外网,则构建失败
6:修改默认本地仓库的位置,可以让Maven核心程序到我们事行准备好的目录下查找插件
1:找到Maven解压目录\conf\settings.xml
2: 在settings.xml文件中找到localRepository标签
3:将
4:将标签内容修改为已经准备好的maven仓库目录
9、POM
1:含义:project Object Model 项目对象模型
2:pom.xml对于maven工程是核心配置文件,与构建过程相关的一切设置都在这个文件中进行配置,重要程度相当于web.xml对于动术web工程。
10、坐标
1:数据中的坐标:
【1】在平面上,使用x,y两个向量可以唯一的定位平面中的任何一个点
【2】在空间中,使用x,y,z三个向量可以唯一定位空间中的任何一个点
2:Maven的坐标
使用下面三个向量在仓库中唯一定位一个Maven工程
【1】groupid:公司或者组织域名倒序+项目名
【2】artifactied:模块名
【3】version:t版本
gav 坐标
3:Maven工程的坐标与仓库中的路径的对应关系
11、仓库:
1:仓库的分类
【1】:本地仓库:当前电脑上部署的仓库目录,为当前电脑上所有Maven工程服务
【2】:远程
a私服:搭建在局域网环境下,为当前局域网范围内的所有Maven工程服务
b:中央仓库:架设在Internet上,为全世界所有Maven工程服务
c:中央仓库镜像:为了分担中央仓库的流量,提升用户俯冲速度。
2:仓库中保存存的内容:Maven工程
【1】Maven自身所需要的插件
【2】第三方框架或工具的jar包
【3】我们自己开发的Maven工程。
12、依赖
1:Maven解析依赖住处时会到本地仓库中查找被依赖的jar包。
对于我们自己开发的Maven工程,使用Mvn install命令安装后可以进入仓库
2:依赖的范围
【1】compile:
对主程序是否有效:有效
对测试程序是否有效:有效
是否参于打包:参与
【2】test范围的依赖
对主程序是否有效:无效
对测试程序是否有效:有效
是否参与打包:不参与
典型的例子就是junit.jar
【3】provided范围依赖
对主程序是否有效:有效
对测试程序是否有效:有效
是否参与打包:不参与
典型的例子就是servlet-api.jar
13、生命周期
1:各个构建环节执行的顺序:不能打乱顺序,必须按照既定顺序来执行
2:Maven的核心程序定义了抽象的生命 周期,生命周期中的各个阶段是的具体任务是由插件来完成的,有三套生命周期
3:maven核心程序为了更好的实现自动化构建按照这一的特点执行生命周期中的各个阶段:不论现在要执行生命周期中的哪一个阶段,都是从生命周期中的哪一个阶段,都是从这个生命周期中最开始的位置执行。
4:插件和目标
【1】生命周期的各个阶段仅仅定义了要执行的任务是什么
【2】各个阶段和插件的目标是对应的
【3】相信的目标由特定的插件来完成
【4】:可以将目标看作“调用插件功能的命令”
14、在Eclipse中使用Maven
1:Maven插件:Eclipse设置
2:Maven插件的设置
【1】installations:手写Maven核心程序的位置,不建议使用插件自带的Maven程序,而应该使用我们自己解压的那个。
【2】user settings:指定conf/settings.xml的位置,进而获取本地仓库的位置
3:基本操作
[1]:创建 Maven版的Java工程
【2】:创建 Maven版的web工程
【3】:执行Maven命令
15、依赖[高级]
1:依赖的传递性、
【1】好处:可以传递的依赖不必在每个模块工程中都重复声明 ,在”最下面“的工程中依赖一次即可
【2】注意:非compile范围的依赖不能传递,所以在各个工程模块中,如果有需要就得重复声明 依赖
2:依赖的排除
【1】:需要设置依赖排除的场合
【2】依赖排除的设置方式
【3】依赖的原则
3:依赖原则
【1】作用:解决模块工程之间的jar包冲突问题
【2】情景设定1:验证路径最短者优先原则
【3】情景设定2:验证路径相同时先声明者优先 , 先声明指的是dependency标签的声明 顺序
【4】统一管理依赖的版本
1:情景举例
这里对spring 各个jar包的依赖版本都是4.0.0
如果统一升级为4.1.1,怎么办?手动逐一修改不可靠
2:建议配置方式
i.使用properties标签内使用自定义标签统一声明 版本
ii.在需要统一版本的位置,使用${自定义标签}统一声明版本号
【3】 其实properties标签配合自定义标签声明数据的配置并不是只能用于声明依赖的版本号,凡是需要统一声明 再引用的场合都可以使用。
16 继承:
1:现状:
Hello依赖的junit 4.0
HelloFriend依赖的junit4.0
MakeFriends依赖的junit:4.9
由于test范围内依赖不能传递,所以必然会分散在各个模块工程中,很容易造成版本不一致。
2:需求:统一管理各个模块工程中对junit依赖的版本。
3:解决思路:将junit依赖统一提取到”父“工程中,在子工程中声明 junit依赖时不指定版本,以父工程中统一设定的为准。同时也便于修改。
4:操作步骤:
【1】创建一个Maven工程作为父工程。注意:打包的方式为pom
[2] 在子工程中声明 对父工程的引用
【3】将子工程的坐标中与父工程坐标中重复的内容删除
【4】在父工程中统一管理junit的依赖
【5】注意:配置继承后,执行安装命令时要先安装父工程。
17、聚合
1:作用:一键安装各个模块工程
2:配置方式,在一个”总的聚合工程“中配置各个参与聚合的模块
3:使用方式,在聚合工程的pom.xml上右键->run as -->maven install
18:cargo是一种专门从事启动Servlet容器的
cargo的网址:https://codehaus-cargo.github.io/cargo/Home.html
1:配置内容
2:deploy报错
Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.2.3:run (default-cli) on project Maven_WebTest: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.3:run failed: C
解决办法:修改一下版本号
19:maven插件地址
http://mvnrepository.com