`
syinhb
  • 浏览: 3423 次
  • 来自: ...
最近访客 更多访客>>
社区版块
存档分类
最新评论
文章列表
背景介绍一下: 1)大家都觉得jdbc原生语句最好用,效率最高,使用最灵活,原因在于他比较底层,借助于人脑的思维,化简了很多问题。但是,他写起来并不高效。 2)ORM工具的出现,为了提高编写效率,封装对象,避免了SQL的接触。但是他不够灵活。 3)于是,ibatis, Mybatis就出现了,他走了中间路线。 问题: 1)所有的ORM工具,对于join都支持不好。原因在于这些ORM太注意OO思想,需要在早期设计POJO时就要考虑多表关系。 这对于以后的更新、升级、维护带来了很多麻烦。 2)如果发现问题,需要修改为适合自己流程的ORM需要改动一些文件,对与老手可能不是问题,对于新手就要阅读很多文 ...
测试了 1自己写的 2java本身 3apache 4spring 代码已经上传, 谢面试简单测试结果 循环1000次 自己编写2->32 java自身1->15 apache3->78 spring4->16 循环10000 自己编写2->125 java自身1->16 apache3->203 spring4->31 循环100000 自己编写2->594 java自身1->203 apache3->562 spring4->219 大家可以自己试试看,代码在附件
热带风光
写了一个贪吃蛇 ,都是想到哪里写到哪里的,很多方法可以抽象的。。。还有很多小bug, 比如蛇可以自己穿过自己,不过这些都是可以在完善的 。 欢迎拍砖
目前持久层框架大概以下: xml配置、annotation、依靠反射。 但是他们或多或少的会存在下列问题: 1。配置复杂 2。入侵性强 3。灵活性不够 最重要的是: 1。多表查询配置复杂 2。返回类型单一,尤其是多表查询后的结果 3。这点尤其重要,凡是不依靠反射的框架,都会存在一旦修改POJO,就要修改大部分配置文件或者DAO文件。 我的框架几乎可以解决以上所有问题。 同时,这是第一版,会存在一些问题,比如,写法冗余,参数传递比较别扭等等。这些问题需要高手们一起帮助解决。 说下大概思路,具体的请看我上传的源代码。 首先创造一个类似于MyEclipse代码生成器的页面。此页面利用DWR创建。 ...
Global site tag (gtag.js) - Google Analytics