瞎扯之项目设计

    最近的工作内容相对来说比较单调，写着毫无业务逻辑的CURD，本文算是一个吐槽吧，亦可以当作瞎扯。

    项目组结构为：一个leader，我和另外一哥们。我的pattern 和我工作经验相当，看起来应该是合作起来比较理想吧。工作内容是重构一个官网后台，以及运营平台的部分整合过来（主要是用户信息，充值、查询等信息）。项目性质：无大并发，数据量略大（已分表，分库处理），99%为CURD,毫无业务逻辑。

    前期技术选型讨论，我主张：Hibernate + servlet + jsp，架构上采用2层架构，直接servlet + Dao,Domain实现。我的pattern的建议 Spring + Hibernate + SpringMVC + Apachel tiles(页面框架式布局） + jGrid组件，分层上仍采用传统的Controller + Service +Dao,Domain。

   先说说我的选型理由和预期作法：

1. 业务性质全是CURD，采用Hibernate可以大大的提开效率，减轻工作量。
2. 还是业务逻辑性质决定，无业务逻辑，故仅采用2层设计，省去传统的Service层。
3. jsp + servlet的交互方式简单，不会增加额外的技术复杂度。
4. 为了处理多数据源，可以自己写一个Hibernate工具类，可以采用Annotaion + ThreadLocal的方式进行处理，解决多数据源的问题。
5. 在表单提交，表单项较多时，可以写一个工具类，完成参数到实体的转换。

    最后讨论的结果是，我的方案被摒弃。采用了我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进行数据交互，被告知这周要完成所有功能。好吧，加班吧，为你们的架构买单。