一个糟糕的Model层设计

在软件设计中，估计模型是最简单的了，一般而言，我们的模型都指的是贫血模型，也就是DTO，正常而言，每个DTO都对应一张数据表，所以在设计模型的时候，大家都没有考虑过多，完全按照个人想法来搞，当然这种在一般情况下，也没有什么问题，但是在多个系统和多个开发人员配合的时候，如果没有设计好，后面还是会带来无尽的痛苦，下面就以我司的一个例子做一个反面教材，如果说的不好或者不对的地方，还请不吝赐教。
现在情况是这样的，有一张表t_x，管理后台为了能够操作这张表，在manager这个项目中，加了一个X1这个模型，Server端为了操作这张表，也加了一个模型X2，但是由于管理台和Server非一个开发人员编写，导致在定义这两个对象的时候，，一些属性名称不一致，而管理台在向这张表插入数据的时候，会保存到Memcache中，而Server端会在Memcache中去取这个对象，但是由于两个对象并非一致，导致取出来，有些属性为空，这是开发人员就做了一个折中，在取的时候，先用管理台定义的对象来承接，然后在将这个对象中的每个属性set到Server定义的对象中，这样Server就能从Memcache中间接拿到自己要用的对象，然后当时这个折中是一个相当垃圾的解决方案，因为后面每次修改t_x这张表，比如新增字段，不仅管理台的X1要新增属性，Server端的X2也要增加属性，还得再从Memcache取的时候进行一下转换，把管理台增加的属性set到Server端对应的属性，从这儿就可以看出这是多么垃圾的一个模型设计，但这不是gc，gc是前两天发现，在client端也有自己的一个模型，这个模型也是针对该数据表的，这样，仅仅这一个表，就对应三个对象，而且还得随时记得增加属性，还得去memcache那边去操作一下，这还不算其他项目中用到的……一想到这里，都不想继续说了。
这部分代码，重构已经是势在必行的了，关于Model层的设计，在此小小的发表一下本人的看法。个人觉得，模型层应该单独抽出，建立一个独立的工程，比如Common，所有表的模型都在此工程建立，建好之后，以jara包的形式，提供给各个模块使用，这样就能保证各个模块使用的都是相同的模型，而且在向Memcache等缓存中放得时候也非常方便，因为放进去的和取出来的都是同一个对象。但是这个也有一个小小的缺点，不够灵活，比如某个项目在表中新增字段，它的去Common工程中增加对象属性，然后再打包，然后替换各个项目中的jar包，感觉上是没有在自己项目中直接修改来的快，不过本人觉得这也完全不是问题，现在有很多手段管理工程的jar包和依赖，比如使用Maven。

评论

1 楼 icefire 2012-10-29  

。。纯粹的管理问题。。