从入职到现在足有一个月啦，昨天刚刚收到那份相当微薄的工资，心情却无比的愉快。这不是我的第一桶金了，但是却是我成为码农后的第一份工资，在我心里有一份特别的意义，也许世上没有比我更二的一个人，这么辛苦只为找到一个所谓的开发岗。说来话长，长的话就不说了。我只是想说说作为程序员第一个月的体会，有些东西，人一生也经历不了几次。老师曾说，每一次跳槽对程序员来说都是一次飞跃，在新的环境的压力，会极大的促使你学习新东西得到成长。能走到现在，算是对我的执念有一点点安慰了。
入职之前，我所做的准备就是spring+struts2+hibernate的java web开发，才一个月而已，我的三观啊。。一年的培训，学到的东西依然不会直接用到，入学前struts2还是炙手可热，现在却流行开springMVC。虽然受了点打击，不过想开了也是安然，毕竟这一行如果没有了技术的更新换代，有限的市场空间迟早会饱和，推陈出新，也是好事一件。老夫聊发少年狂，尽管来吧。
框架虽然变了，但是究其根本，需求不变，业务流程也就换汤不换药。只要心里有项目，框架也不过是个工具。项目的每个环节，环环相扣，站在全局高度上去理解，就不会深陷在框架的细枝末节。一个web应用，不管是springMVC还是struts2，都是mvc框架，就是一个jsp视图层，加上业务逻辑曾下面的那些东西，然后通过控制器连接起来，而springMVC就是这个控制器，变化的只是这一点而已。控制器需要做什么呢？获取http请求，返回jsp路径或者直接返回响应内容，根据需要配置javabean。通俗的说就是这些，通过这些，我们就能实现大部分业务需求。经过几天时间的摸索，我发现springMVC居然更容易了，属性注入只需要方法传参，不需要专门写成员变量，这种方式应该说更合理。
还是集中起来说说吧：1、上面写的属性注入，其实还有一点，自动封装，连modeldriven都省了；2、通过@RequestMapping注解，可以定义访问url，入口就有了；3、返回视图，这个springMVC就有点故弄玄虚了，整了个ModelAndView，刚开始就把人吓半死，其实根本用不到，还是直接return字符串路径，这个需要看好配置里写的前缀和后缀再写；4、返回json，这个，呵呵全自动的，不管是什么对象啊，集合啊，字符串等等，一个@ResponseBody全部搞定；5、至于javabean，传参的时候可以带request，response，好了，你知道该怎么办了；6、配置文件，这个刚开始也费了不少工夫，但是理解了大体构造后，发现springMVC就是从一个拦截了所有请求的servlet，配置里就是说要用封装好的那些类来处理请求，这些东西基本都是不变的，所以最后直接一个mvc标签就全代表了，这就是注解驱动，然后定义是图层的处理类声明的时候，顺道把jsp的前后缀写了，还有什么来。。。自动搜索注解组件，写个包名规范，这个就更好理解了。
掌握了这些之后，心里开始踏实了不少，至少不会一筹莫展了，这个项目还是用的还是hibernate，所以如果我想的话，至少可以发挥出原本一半的实力了，springMVC的障碍就这么扫除了。心里有一点小得意，写了点表单数据库增删改，感觉自己萌萌哒。其实有了这些功能做基础，再做其他的事情也就是js加工处理一下，加点css样式，程序性能上的问题自然有人早处理好了，搭框架的时候的事情了，b/s项目本来就是这样，没有c那么麻烦，要想什么内存之类的。对于我来说，初来乍到，能在别人的框架上做点自己的功能，应该是要保住这份工作最先要做到的，然后我就能作为这里的一员生存下去，不错，生存，这就是。。我要做的。这又是另一个话题了。
想想那时候，我所担心的，应该怕是有什么过滤器拦截器之类的东西，会对我写的功能产生不可预料的影响，所以又倒回去看配置文件，完全没有注意到前台的封装问题。看了几个项目之后，发现有一个共同点，就是都会对数据列表做封装，然后查询，分页，表格样式都会被集成在一起，这个也是要花费一定学习周期的。如果要做出能用的东西，就一定要保持风格上的一致。所以研究前台样式才是我该考虑的事情，然后我就完全放下了对springMVC的学习，其实我在看那本书的时候，发现springMVC真的要用好用活，多了解一些细节上的东西还是很有价值的，但是我还是决定暂时一放，那本书叫spring in action，有兴趣的可以自己找找。
这个前台的封装我看了很长时间，其实我有感觉，老大在这个阶段对我的表现不太满意，做个带样式的增删改查要这么久。我很感激他的宽容，他没有说什么，对我很有耐心。其实他只是不知道，我在做没有样式的时候是按照我以前自己写的项目的逻辑考虑的，加入了很多js的判定查询和分页的东西，希望他看到我的代码的时候能给我加点分，可惜他没有看。后来写带有样式的功能，我基本上要把原来的封装给玩坏了，也许之有原来的作者才能像我这么灵活的调用这些功能。可惜他没有等我全做完，就给我安排其他事情了，至于代码，他还是没有看。也是，现在的我，写的东西也没有什么用，为什么要看呢？终于，他说要我做点有用的东西，我想，我该认真起来了。这一次，我没有做其他的工作，因为用的就是之前看的系统，只是实现功能的话，已经没有任何障碍了。翻出之前整理的几页操作要领，开启万花筒写轮眼，进入坐忘的境界，呵呵，只用了两天，我完成了他想让我两周做的事，“这不是挺快的嘛”，他的自言自语，原来他以为我很慢，了然。我很庆幸，这一次让他改变了之前对我的看法。我知道，自己的思维习惯很多时候都。。不太一样。所以总是被曲解，为此吃了不少亏吧。所以我宁可少点说话，虽然我也有颗不甘寂寞的心。还是用实践来证明自己吧，这是我这种人唯一的出路了。后来，几次修改需求，我都改的很快，“神速”，我很喜欢这个评价。当然，我还是一个新手，我知道，我还差的很远。
说完springMVC，该下一个话题了，习惯了第一个平台之后，老大总算舍得调高难度了，不能让他失望，这一次的boss是myBatis，其实spring也早已不是原来认识的模样了，只是都是不知不觉间的习惯了。这个平台更庞大，但是我现在的感觉是还不够灵活，建表什么的如果用自带的codegen，很难做出合适的主外键关系，所以我试着打破封装，直接操作myBatis，这样很多封装的方法都不能用了，我想了个伪造封装的方案，只是还不够完善。
myBatis这个东西，应该是把model和dao耦合到一起了，查询写到mapper里，难道说mapper就是dao？然后通过mapper的id和namespace作为statement，由sessionTemplate为crud做不同的session。那么dao方法就只有传参的作用了，具体查询都由映射文件来定义。单个表的查询没什么好说的了，确实很直观。多对一，这个东西要写resultmap标签，和一对一一样的形式，需要的地方把result改成association，多写个select属性，而一对多，这东西我一般是不用的，看了下也是用个集合，然后标签写的collection。mybatis的懒加载默认是关闭的，
<settings> <setting name="lazyLoadingEnabled" value="true"/> <setting name="aggressiveLazyLoading" value="false"/> </settings>
这样子打开懒加载。
但是如果懒加载是开的，又怎么读数据呢？
天太晚了，明天加油！