当我们聊JavaWeb的时候，我们聊些什么

首先感谢一些并不认识的同学的关注，从0到1的突破，真的挺欣慰的，希望在以后的日子里一起进步。
最近多少有些浮躁、焦虑，mac坏的几天里，手写了这份提纲，总结一下过去，掌展望下未来。
都是基于自己的理解，可能有点偏差，而且分层分的也不是那么严谨，欢迎批评指正。
本文结构目录

不得不说的B/S架构、对应的数据流向模型

.学习后端，这个是必要的了解。现在主流的开发模式是基于浏览器做前端展示、输入、反馈对接用户（常说的前端部分）得到一组响应数据
然后后端将前面的数据进行分流、运算处理，一部分返回给前端、一部分写入数据库。
看到这，脑子里应该有一个最基本三层结构出来了。其实去年自己还迷迷糊糊，但是知识这东西确实只有自己动手做过了，才能够有更深的理解。接下来讲的所有的东西其实都是围绕着三个层面展开。
这块有个大概的数据流，我觉得是整个开发或者学习蕴藏的很重要的主线。

第一就是跑也跑不掉的http协议，我们之所以有能在三层之间来回跑的东西，要感谢这个协议。这个协议里面最基础的两辆车，从前往后跑的车叫做，request车。他有个兄弟，喜欢反着干。从后往前跑的车叫做response车。他们每时每刻穿梭在互联网，带着我们的数据跑来跑去。你在浏览器（泛指所有前端：手机等）输入的琐碎数据。
我们统统装车，装车的时候，我们会问问你，是走get车道还是post车道，基本上可以说get车道是明道，装啥玩意，别人一看就知道了。

post车道比较黑，我们习惯把车上盖一块布，把你锁碎的信息货物装到车里，不太容易一眼看到，而且这两个车，能拉的货物吨位也不一样，一般来说post拉的多。get如果超载，到货场，货场那边也不一定要他，容易被拒收。但是一般来说，get快一点，比较直接，发车的时候直接带着货物，直接奔货场就去了。post一般稳一点，发车前一般打个电话给货场。或者先去一趟货场（详见计网）
不管咋说吧，这两个车都是跑在名字叫TCP的路上，川流不息。

老生常谈的MVC

最早我做的纯JSP,项目是没有控制层的，只有前端、服务层、dao层，所以当时我理所当然认为MVC设计模式就是三层架构呢。。 后来将服务层分离开的一霎那，我傻了啊，这不四层了吗（前端jsp-后端控制层-后端服务层-后端持久层）？开个小玩笑，手动滑稽。。
常常说mvc设计模式，其实是很多设计模式中的一种。这种设计模式，被广泛应用在实际的开发过程中，相应解决了很多实际开发管理、效率问题、逻辑清晰。。。
来我们看看百度的定义
经典MVC模式中，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。其中，View的定义比较清晰，就是用户界面。

自己的理解

结合上面的玩笑，来讲下自己的理解。再往后有一个开车模型，可以好好理解一下。

m：业务模型这东西我现在暂时理解就是，整个数据流从控制层往后，所有跑在你代码里面的数据该怎样交换、处理。具体来说我觉得有两层，服务层，持久层。他们定义了你后面数据流的动作。

v：上面定义也说了，这层比较清晰。毕竟我是一个后端嘛，什么都不管，前端别扯皮就给你这个，你就给我这个，上来就是一梭子json格式的数据。。
那么说所有的前端展示都归于这个层了。

c：控制层，是数据的交警，但不是工厂的工人。后面具体解释。简单说，在上一个项目里面我们从前端拿过来的数据，通过一套交通规则（xml 文件映射），来到了公路上，见到了我们各式各样的servlet交警，交警指挥你去各种小道继续前进。

这是交警的第一个作用，指挥方向。第二个作用，交警看你大车不行啊，不能上小道，不符合县城的小道规则，命令你换车。那么好你的request车乖乖都变成了，java数据流车了。
这是交警第二个作用。你不用担心车的问题，到时候你再回到主道上的时候，交警自然会把大车还你（response）。

嘿嘿，我知道大家都喜欢开车，，那就继续聊开车。。

request车装上你的信息，先到后端服务器上报个道，问问那里的服务器交警上哪停（到了控制层），交警说你先等会，在这查下驾驶证，你说你不是第一次来啊。交警说：你这没用，你的数据车乖乖拿着cookieID给交警看下，交警查了一下session，嗯确实有这么车和司机，去吧，给老子换个车先（变成了java数据流，顺利通过登陆中的session检查）。要是第一次来呢？乖乖登陆吧孩子等交警给你cookie小饼干吧。

去市中心看看。然后车被第一层交警（后面说的控制层）指挥、分流去了那个工厂，到了工厂（服务层）。 工厂又有很多门，幸运的是交警已经告诉你到底走那个门，（具体的服务层接口）。
车到了工厂里面，工人问了问，你这货到底是什么。。
然后工人决定是卸车还是再装车，或是再去别的厂子看看？（–转发–）
好了你的车，我们假定就到这里完成了他的使命。
再看看厂子里的工人。
你的货物来的时候是一大坨（我以前将前端琐碎的数据，在控制层拿出来，组装一个大的对象–我们称之为实体类，我们用他装在java数据流里面跑来跑去），然后你到了厂子里面工人卸车的时候，还得一个个的拆开。（这个过程就是上面b/s架构 中服务器，向数据库写入的时候，我们有个高逼格的词语，持久化）好吧，这样是真的麻烦吧，啥也不说，一梭子json干他吧。
json是一种数据格式，本质还是http那两车，只是车升级了，这回我们可以之间从前端拿一个对象了。到后端数据库的时候，到了工厂，工厂也升级了（像mongoDB这种数据库），工人直接把对象卸车，不用拆开了。。

对jsp项目中细节的反思

1.数据结构方面：
当时有这么一个情景，我需要向数据库中插入和读取一个用户对象。（这块要说一下，一般我们有几个实体类，我们数据库就应该至少有几个相应的实体表与之对应。。） 当时这个管理员对象中有一个角色属性，角色也是一个实体类，他里面有一组权限属性。所以你看的出来这是三张表的插入和读取。

当时我们从一个大的list集合取用户，然后取完用户之后，我们得再去取，他的角色，再去取他的权限。这个时候，涉及到一个大的while循环，当时我们是设置一个索引键值，来判断是否对这一个用户的操作到此为止了（那样就开始下一个用户的读写操作嘛），但是后经老师点拨，这就是一个活生生的hashmap使用场景，我们利用这个数据结构键值的唯一性，来实现判断就可以。这个改造暂时没做，先写到这里来提示自己。
登陆的时候密码 md5的对比，下面有说为什么对比的是两个md5值对比。这边考虑用KMP或者字符串hash去处理它，提高性能。

2.前端方面：上一个项目前端基本上是比较基础的原生代码写的，没有过多涉及到框架，开发效率很低。

3.各种工具类的细节-控制安全
1.暂时想到一个密码加密的md5工具类的使用，使得我们存入数据库的密码是经过加密的。但是暂时没有添加登陆时候，密码对比的代码。因为我们知道md5是一次加密，无法反编译回来，我们只能通过撞库去对比。这个实现起来不难，同样的登陆的时候，我们生产一组md5去对比后端的数据库里面的密码就可以了。但是要考虑算法了，毕竟这么长的串，你用基础的循环多少有点说不过去吧。
还有一个小细节，不太清楚，dao层里面预编译能否防止sql注入呢 预编译的sql语句要是能防的话，是不是应该都变成预编译的呢。。。

4.登陆和文件上传的细节
登陆的时候的cookie和session的应用，暂时还没加到项目里面。
文件上传到的时候服务器上，再去取的时候，路径要设置成服务器路径，写项目的时候，经常疏忽这点。而且上一个项目是龙哥写的工具类，还没有细致看过里面的机制。

从当下细节的展望

如何从jsp项目中联系上他们口中好高端的框架呢？
聊下常说的ssm已经设计模式等等
回首看看之前的 control层 servlet层 service层 dao层

可能现在很多哥们一交流说，jsp项目说这么多干嘛？
上框架啊，但是框架说到底，也就是对基本的原生开发的一个开发效率等东西的提升。我回头看这个jsp项目的时候，还是心存感激的。（原生代码量真大啊！！！）

1.我眼中的软件危机：就是代码写的很多的时候，确实不好管理，这么说有点强硬，但确实真的是有点乱，因为用了mvc的框架所以后端杂乱的程度真的解决很多了。

但是有时候还是会出现冗余，我记得涉及到多表的时候，在一个service里面就会有交叉的dao层，等等吧。
也就是说当功能点变大时候（商务软件开发，需求点变多时候），我们原始的框架还能否支撑的住。
请读者自行搜索软件危机。。
方向1
总之这块的话，要设计出、管理好优秀的软件项目，我们要多了解几种设计模式。。软件体系结构等等。spring也代表了一种优秀的开发模式。直接说的话，应该就是快速开发、适应企业级项目的框架。让你快速成为打工人？

2.耦合程度：因为我们分了上面说的四层（从控制层到dao层）每一层调用下一层的时候，都要new一下，具体我也不知道怎么产生耦合的。可能因为一旦下层改变的话，上层就要改变？？
spring靠其ioc的思想解决了这个问题，尽量减少松散，接耦合。（jsp项目中后端的整体代码）

3.springmvc，暂时看是代替了我们上一个项目中xml的作用，实现http到后端程序数据的分流。（jsp项目中的xml以及控制层）

4.最后说下dao层，dao层我们后面，利用mybatis或hebinate框架去实现持久化。（jsp的dao层）dao层还要分享一段话：DAO指的是数据库访问对象，我们用这种设计模式将底层的数据访问逻辑和上层的业务逻辑分开。
自己理解就是，其实大公司（听说）很多都是一个人负责一层，不是全部奥，所以说我如果是作为service层开发，我不关系你dao层写的什么玩意，我看一眼这个接口能用就行。上面说过，在dao之前上面都是对象的形式，dao这层我们才把它变成sql语句。显然service层的开发，更喜欢对象操作啊。。

4.后面数据结构与算法的应用等东西的加入
底子硬才是真的硬，比如说上面提到的kmp算法

发自内心感慨一下

写这篇文章主要是给自己看的，这是当然。但是真的是因为自己一路学过来，很多时候看不到后面是什么样的，我现在学的是一个什么东西、、等等这种迷茫不知所措。
所以另一个很重要的就是再督促自己，加深后面学习的时候，也真能帮助与我一样的小白，在此时此刻能够大概形成一个大致的印象和感觉。当时真的没人跟我说这么多，我也是走到这步才懂那么一点点。
再次感谢关注我的同学们，祝你们期末顺利，前程似锦！