为何重复造轮子

重复造轮子，意思是说，一个项目本身存在开源组件，但开发团队还是选择重新手写一套组件库或框架的情况，这在软件业界比比皆是。

下面说下游戏项目里重复造轮子的几点原因。

一，精简化

一般开源项目为了适应多场景多业务，底层不可避免的需要深度抽象。在更好地支撑上层业务的多样性的同时，也牺牲了开源项目本身的敏捷性和灵活度。

例如Hibernate很强大，但很复杂，其提供的绝大部分功能在游戏里都没有用武之地。游戏项目对于数据库的操作有以下几点特点：

• 绝大部分是增加、查询、修改
• 很少进行删除操作
• 极少进行联表查询

针对游戏项目，我们完全有理由重新造一个最小化的orm工具库。

二，适配性

JPA接口虽然提供了针对数据库列数据与对象的转化

package javax.persistence;

public interface AttributeConverter<X, Y> {

    // 对象属性转为数据库列数据
    Y convertToDatabaseColumn(X var1);

    // 数据库列数据转为对象属性
    X convertToEntityAttribute(Y var1);
}

但遇到游戏项目经常使用到的json工具库（主要是jackson）便显得有些捉襟见肘。原因是我们经常在业务代码用jackson来序列化一些泛型数据容器，在将字符串转为实体属性的时候，如果没有实体属性本身的class信息，是无法反序列化成功的。

针对以上问题，我们重复造轮子的时候，就需要对orm工具的接口做适当适配

package jforgame.orm.converter;

public interface AttributeConverter<X, Y> {

    // 对象属性转为数据库列数据 
    Y convertToDatabaseColumn(X attribute);

    // 数据库列数据转为对象属性， clazz参数是新增的
    X convertToEntityAttribute(Class<X> clazz, Y dbData);

}

三，拓展化

目前的orm工具库，对实体的修改都是整体修改。也就是说，假设数据库表有50个字段，业务代码只修改了其中一个字段，orm在保存的时候，仍然是50个字段整体修改。在我们重复造轮子的时候，可以在自己的工具里加入修改单表指定字段的接口。

更进一步思考，我们可以在实体属性发生变化的时候，程序自动监听到属性发生变更，然后定时把收集到的变动字段持久化到数据库。这种思路可以参考下这篇文章。

Java实现数据劫持——监听属性变更