工作笔记-架构
2006-09-25 13:56
232 查看
合作公司的人说:他们的架构已经达到任何不懂开发的人员只要经过简单培训就能开发出一套电子商务系统。但是,合作公司的架构原先并不是为电子商务系统而设计的,难道说他们真能设计出这种“万金油”类型的架构?结论是:不可能。合作公司为了自己的商业利益是不愿意去大量修改已有架构,他们更愿意是不管能不能用都将就用。
一个不懂开发的人员经过简单培训后使用他们的架构或许能碰巧完成一个增、删、改、查的功能。但是,这些功能的业务代码是没有经过测试的。这个架构的开发方式是大量的进行复制和粘贴,如果仅是读写数据库的代码,这种复制粘贴倒也不会产生多大的影响。但是一个电子商务系统远远不是读写数据库这么简单,中间掺杂复杂的业务逻辑。如果不对实现这些业务逻辑的代码进行单元测试,那么结果就是数据库操作是正确的但是结果是错误的。
另一方面,架构本身设计上对公共组件没有进行合理的抽象,例如在数据访问层没有定义接口,每个数据访问层方法必须传递一个数据操作对象。为什么要进行这样的传递?为什么数据操作对象要污染数据访问对象?如果在这个框架中非要传递,那么为什么传递的是一个类而不是一个接口?在异常处理上,为什么要用返回值?为什么不定义有意义的异常?在业务逻辑层需要构造数据操作对象来传递到数据访问对象中,业务逻辑层应该只处理事务相关的事情,为什么不抽象出这类代码?为了完成查询,这个架构要求涉及到查询的AcitonForm必须有一个接口两个类,为什么不将查询抽象出来?
总而言之,这并不是一个架构。
一个不懂开发的人员经过简单培训后使用他们的架构或许能碰巧完成一个增、删、改、查的功能。但是,这些功能的业务代码是没有经过测试的。这个架构的开发方式是大量的进行复制和粘贴,如果仅是读写数据库的代码,这种复制粘贴倒也不会产生多大的影响。但是一个电子商务系统远远不是读写数据库这么简单,中间掺杂复杂的业务逻辑。如果不对实现这些业务逻辑的代码进行单元测试,那么结果就是数据库操作是正确的但是结果是错误的。
另一方面,架构本身设计上对公共组件没有进行合理的抽象,例如在数据访问层没有定义接口,每个数据访问层方法必须传递一个数据操作对象。为什么要进行这样的传递?为什么数据操作对象要污染数据访问对象?如果在这个框架中非要传递,那么为什么传递的是一个类而不是一个接口?在异常处理上,为什么要用返回值?为什么不定义有意义的异常?在业务逻辑层需要构造数据操作对象来传递到数据访问对象中,业务逻辑层应该只处理事务相关的事情,为什么不抽象出这类代码?为了完成查询,这个架构要求涉及到查询的AcitonForm必须有一个接口两个类,为什么不将查询抽象出来?
总而言之,这并不是一个架构。
相关文章推荐
- 工作笔记:ffmpeg ios 打包 所有架构包括 arm64
- Android系统架构(简述)——《深入理解(I)》学习笔记1
- 各大网站架构总结笔记
- 优酷网的架构学习笔记
- 笔记:大型网站的核心架构要素
- RESTFul架构学习笔记
- 设计模式笔记之一:MVP架构模式入门(转)
- Hadoop学习笔记一:MapReduce的工作机制
- 各大网站架构总结笔记
- 【SpringMVC架构】SpringMVC入门实例,解析工作原理(二)
- 大型网站架构学习笔记
- 高性能mysql笔记---mysql架构[-1-]
- zeromq源码分析笔记之架构(1)
- 大型网站技术架构-核心原理与案例分析-阅读笔记02
- ARM处理器架构----处理器的工作状态
- 7月19日工作笔记
- 工作笔记:linux绑定CPU、软中断
- HDFS笔记(特点、原理与基本架构)
- 培训笔记(新架构)
- 用微软.NET架构企业解决方案 学习笔记(一)