工作笔记-架构

    合作公司的人说：他们的架构已经达到任何不懂开发的人员只要经过简单培训就能开发出一套电子商务系统。但是，合作公司的架构原先并不是为电子商务系统而设计的，难道说他们真能设计出这种“万金油”类型的架构？结论是：不可能。合作公司为了自己的商业利益是不愿意去大量修改已有架构，他们更愿意是不管能不能用都将就用。

    一个不懂开发的人员经过简单培训后使用他们的架构或许能碰巧完成一个增、删、改、查的功能。但是，这些功能的业务代码是没有经过测试的。这个架构的开发方式是大量的进行复制和粘贴，如果仅是读写数据库的代码，这种复制粘贴倒也不会产生多大的影响。但是一个电子商务系统远远不是读写数据库这么简单，中间掺杂复杂的业务逻辑。如果不对实现这些业务逻辑的代码进行单元测试，那么结果就是数据库操作是正确的但是结果是错误的。

    另一方面，架构本身设计上对公共组件没有进行合理的抽象，例如在数据访问层没有定义接口，每个数据访问层方法必须传递一个数据操作对象。为什么要进行这样的传递？为什么数据操作对象要污染数据访问对象？如果在这个框架中非要传递，那么为什么传递的是一个类而不是一个接口？在异常处理上，为什么要用返回值？为什么不定义有意义的异常？在业务逻辑层需要构造数据操作对象来传递到数据访问对象中，业务逻辑层应该只处理事务相关的事情，为什么不抽象出这类代码？为了完成查询，这个架构要求涉及到查询的AcitonForm必须有一个接口两个类，为什么不将查询抽象出来？

    总而言之，这并不是一个架构。