一直在困惑我的事情 经典的理论 n层架构 xx设计模式 o/r mapping
我这里讨论的问题仅仅在于数据库和业务系统方面的问题 先不考虑 其他媒质
通常我们采用了很多非常优秀的架构以及设计模式 由于项目的不同 或者说业务的不同大多采用了很多代码生成工具 如codesmith 甚至于有人热心做模版而使得开发上有非常不错的便利性. 说实在的 这些设计是非常通用的 基本上每个开发人员都能说出点什么来.
那么好 问题来了 就以n层架构为例,如果 用户的业务需求变动了 如果需要增加点数据库字段 调整一下 sql查询的脚本 有没考虑过 需要修改多少东西?当然 你可以说有代码生成器 可以方便点 但是当你已经写了很多代码的时候 你会觉得有帮助 但帮助不大.于是 我们会强烈要求需求变动 我们需要时间修改 我们需要时间测试.....
当然 对于大型系统来说 这里我的定义是非常大型(因为我没考虑过超大型的应用,毕竟那包含的内容太多)采用一些经典的架构模式是非常好的,而对于中小企业 产品 项目 越快 投入越少,时间 就是钱 投入的人力是钱,经济危机下 生存真难
是否可以考虑配置方式? o/r mapping 难道在代码里做 就是o/r mapping ? 难道 一个个表可以考虑成对象集合?为什么不把这些作为一个对象中的一部分?表或者说查询 那些操作 为什么不是一个属性? 难道表里增加一个字段 还需要我们去修改程序不成?为什么不去考虑程序的可伸缩性呢? 把业务或者说架构抽象出来 难道不是一种解决方法吗?
界面 展示方式 都可以穷举 为什么不采用自定义呢?这样做 项目越多 我们花的代价越小
在关注技术的同时 也必须考虑 技术的生存在于带来多少市场效益
未完 待续.......................
最新评论