最近的工作内容相对来说比较单调,写着毫无业务逻辑的CURD,本文算是一个吐槽吧,亦可以当作瞎扯。
项目组结构为:一个leader,我和另外一哥们。我的pattern 和我工作经验相当,看起来应该是合作起来比较理想吧。工作内容是重构一个官网后台,以及运营平台的部分整合过来(主要是用户信息,充值、查询等信息)。项目性质:无大并发,数据量略大(已分表,分库处理),99%为CURD,毫无业务逻辑。
前期技术选型讨论,我主张:Hibernate + servlet + jsp,架构上采用2层架构,直接servlet + Dao,Domain实现。我的pattern的建议 Spring + Hibernate + SpringMVC + Apachel tiles(页面框架式布局) + jGrid组件,分层上仍采用传统的Controller + Service +Dao,Domain。
先说说我的选型理由和预期作法:
- 业务性质全是CURD,采用Hibernate可以大大的提开效率,减轻工作量。
- 还是业务逻辑性质决定,无业务逻辑,故仅采用2层设计,省去传统的Service层。
- jsp + servlet的交互方式简单,不会增加额外的技术复杂度。
- 为了处理多数据源,可以自己写一个Hibernate工具类,可以采用Annotaion + ThreadLocal的方式进行处理,解决多数据源的问题。
- 在表单提交,表单项较多时,可以写一个工具类,完成参数到实体的转换。
最后讨论的结果是,我的方案被摒弃。采用了我pattern的方案,leader交所有的设计交给他。好吧,我就重建了我这个模块的实体,测试。经过3个周的工作,至目前为止,整体框架才算稳定。
首先在spring版本上,采用3.2,要springMvc 注入 dao Service时出了问题,因为采用了2个Context, 在Service层加上事务时,springMVC注入的处理,3.2的处理与3.1上还是有所不同的。这算是一个盲目采用新版本所带来的问题。
其次,Dao,Service设计上,采用 接口----实现的方式来做。 在这个问题上,我坚决的提出反对,我最反感为了接口而接口,往往喜欢用这种方式的人,都是为了说扩展性,那么我想问一下,在你所经历的项目中,有多少项目上线之后,后续对Dao,Service进行了整体扩展的? 倘若没有,那么为何要设计这个接口?部分方法的的扩展,完全可以通过重载等方式进行。那这么多接口,除了徒增了工作量,复杂性,还带来了什么?有人说,带来了标准化。 那我想问:标准是什么?标准是人定的,采用接口---实现就是标准?那在没有多态的地方直接用实现类,就不是标准了? 只要一个项目里面统一风格,难道不标准么?有人说在分层开发中,即dao,service,controller分别为不同的人开发时,采用接口--实现类的方式有优势,我承认,这种场景这种方式是有一定的好处,但是用类就做不到么?定义空方法给上层程序员用就不行了么?在这里,我再一次被强力否决,leader与pattern都强力否决了我,理由也就上面的这些之类的云云。
最后,就是页面表格组件,因为他选型,所以这个JGrid组件,我没有去深入了解,都是他向我解释怎么用。表格的数据来源方式,一定要通ajax方式,导致我们在controller中,必须先写个跳转到页面的方法,跳转到列表页面,然后定义一个获取数据的方法,能ajax调用来加载数据。 其实这点我是怀疑态度的,我觉得做为一个组件,这种方式显然显得有些傻B,就算不支持,也可以自己修改扩展达到。结果又被否决,首先他告诉我,我期望的方式达不到,其次否决修改组件来扩展的方式,避免以后升级的问题。 这个理由,我又再一次不同意,一个表格组件,你老是升级他干什么?
如果一个技术你掌握不了,那就不是玩技术,而是被技术玩。至于公司的组件这些类,应该是趁空闲,或者是专人进行编写,或是找开源的进行自己扩展,以符合自己的需要。
我分配的几个模块的后台,早就写好了,也用junit测过了。这周才能开始与jgrid进行数据交互,被告知这周要完成所有功能。好吧,加班吧,为你们的架构买单。