java开发中常用的框架其实就是几个，spring(mvc)，hibernate，mybatis，lucene,使用的数据库也就那么几种，mysql，redis，memcahced，mongodb。在遥远的“远古时代”，我们习惯了用jsp+servlet，进化到了struts，然后ejb->spring。。。就没有然后了，我只能说我们习惯了。老外总结了开发的难点并且把重复的工作封装后提供我们使用，而我们就习惯了别人的那套方式，这样到底好吗？
不可否认，老外在软件开发以及软件过程方面的总结确实有一套，并且能进化成产物，但是他们封装框架的时候考虑的是大而全，什么叫大而全，颗粒度适中，但是结合业务的时候还是有一些粗。
所以我不会去重复造轮子，只是考虑基于常用框架(spring(mvc),mybatis,lucene,hibernate),适当的再进行一次薄封装，把原本颗粒度较粗的代码，细化一点。能让java也能快速开发.缩短我们的开发周期。
为什么要基于框架进行开发?使用框架的好处很多，它规范了我们的开发方式，减少了出错的可能性，让我们可以更快地完成开发目标，后续维护也可以有章可循；使用框架的弊端也很明显，它束缚了我们，离开熟悉的框架进行开发我们可能会手足无措，它让我们身陷其中。
在sense开发的时候我一直再思考一个问题，到目前为止，我所认识的框架无一不例外都是以 class 作为实体类型的，为什么会这样？为什么不能以其他形式（例如 map）作为实体载体？我觉得这些问题很值得讨论（虽然以前可能已经讨论过无数次）、很值得进行实践。
记得曾经看过一本书，里面有一段ibatis作者（当时还不叫mybatis）的采访，貌似他是这个意思“ibatis为什么要支持map，因为我觉得应该支持，但是我不建议使用map”，这句话是什么鬼？，实现了map支持，但是不建议用map，我思考了很久，其实在orm的上，我也是不建议使用map的，但是在我封装sense-support-myabtis的时候我觉得我想法错了，我希望的数据调用模型是ddd，但是在mybatis的基础上进行这样的封装，并且将sql模型和数据参数传递给底层，必须使用map，因为只有底层对map的支持，才能让我们不写重复繁琐的sql，有兴趣看看源代码吧，但是对于码农同学来说，调用业务方法的时候还是不要用map传递数据的好。
然后我发现我又错了，在封装openapi请求参数接受的时候，我发现request(我用map接收的，但是可以指定泛型为class，代码里面没实现，其实就是一句判断的问题)，我觉得这里接收用map更好，想想我们的servletreqeust的方法，其实就是map的感觉，更加灵活，在业务变动的时候我压根不需要去管理什么dto这种鬼东西。难道不是吗？
今天先写到这里，后面慢慢聊。。。。
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于