数据持久技术
当持久化兴起的时候，逐渐形成了实体层这个概念了。hibernate,jdo,以及博客园的nbear都可谓是大名鼎鼎！有的公司不使用这种ORM框架,他们使用一些自动生成工具生成实体(例如用Codesmith生成)，并生成和该表对应的业务逻辑，于是乎感觉我们的程序好像一下子全都写好了，下一步就轻松了，我们只要扩展业务即可了!莫非这样真是那么方便了？在维护上真的是最便捷吗？ 其它的持久层解决方案不敢说，但至少我觉得像orm的鼻祖hibernate那种开发机制,在维护还是相当之麻烦呀！一个实体还得对应一个xml文件（虽说这些都可以自动生成）,但是你深入项目的时候去想想，我们的业务真能一切都可以定下来吗？人的思想总是在变的，客户的需求就更难以着磨了！哪天我们要给程序加个字段，你想想你必须要走几步改动？首先我们必须重新生成xml和实体，然后我们必须还得在业务逻辑中增加代码，还得在视图层加一个界面(如加一个input输入框等)！讲实话，加一个字段对这种orm框架的改动还是最少的，哪天假如说我们修改了哪个字段的名称、修改了字段类型，你想想，天呐！很难想像，和这个字段关联的程序都得改动!如果名称改了，ok，你可以全部替换它的原先名称，改成你新的名称。那类型改了呢？没办法只能手工一个个改掉所有的赋值的类型吧？视图层、控制层中的验证（js验证,业务验证）、逻辑层、实体层，xml配置等等都必须动。搞啥个hsq，这和sql不差不多了吗（虽然说hsq，抽象了数据库模型）？不过我想没有程序员不懂sql的吧？况且hsq对复杂的语句还是会力不从心的吧！