最近在读一本书《敏捷软件开发 原则、模式与实践C#版》，其实这本书买了一段时间，一直忙于做事，读CSLA业务对象那本书。最近一周多，才开始看。这本书侧重于软件的开发方法，就是整样面向对象的方法来设计软件，以提高代码的复用，可维护性。这本书，主要讲了两个大例子，原则那一块主要讲了一个“咖啡机”，怎么样实现咖啡机软件控制，实践那一块主要讲“薪水支付系统的设计与实现”。这其中，也穿插了设计模式的讲解，举了大量的小例子。以及一个开发思想“测试驱动开发”，注重单元测试。
其实，这本书，一开始的版本2003年就有了，当时是C++的，后来出Java的，直到最近才有.NET C#的，这本书中的“咖啡机”例子实际上是作者的另一本书中的《UML Java程序员》，当时我也看过，几年之后，再看，理解更加深刻。从琐碎的类中，提练出真正的类，而这些类，是接口或抽象类，对底层的实现根本不关心。最后的类，就3个，一个水源类，一个托盘类，一个界面类。这样的设计，可以扩展成许多其它的系统，只要是加热、保温类的，都可以用，作者甚至还说水源可通过水龙头接入。
再看“薪水支付”的，对雇员的工资，要考虑以下几种情况。
1雇员类别，是临时工、月薪、基本加提成的。临时工，是按小时计薪，超过8小时，要支付加班工资，他们是依据每天的工时卡。月薪，是每个月固定薪水。基本加提成的，类似于销售员，业务员，他们的提成，以依据每天的销售业绩。
2发放时间，是每天结算，每周结算，双周结算，还是月结。
3发放方式，是形成支票放在财务，还是直接打到银行账户，还是支票寄到家里
4工会扣费，员工可能参与公司的工会或社团，这样他们要交纳一笔费用，一个员工可能要加入多个社团，在员工结算薪水时，要作扣除，因为发放时间不一样，所以每次扣的多少也不一样。
设计这样一个系统，看似简单，其实要考虑的东西也比较多。书还没读完，但我感觉这里的设计思想比较不错，对于类别设计一个基类PaymentClassification，下面再继承这个类SalariedClassification，HourlyClassification，CommissionedClassification，共性的东西可以提到上层，个性的东西在下层改写。应用程序，只操作基类，当然，实际运行时，还是根据程序的状况调用实际的扩展类。其他上面的，也是这种思想。对于数据访问，有内存的模拟数据库，有实际的SQL Server数据库，应用程序只是在操作上层抽象的东西，这样的系统维护起来是相当方便的，改动量应该比较小。
再回顾开发的一卡通系统，实际上球类，如羽乒台，羽毛球塑胶场、羽毛球普通场地、中式台球、花式台球等等，都是一个独立的对象。特别是，康体中心的一些球类项目，现在是与场地的程序整合在一起，而他们的计费方式是不一样的，场地精确到半小时，康体的一些精确到15分钟，所以在计算费用时，引入了一些Switch Case的语句，程序的耦合程度较大，好的程序是“高内聚，低耦合”的。如果用户需求发生变化，如新增一种计费项目，如果处理不好，会影响现有的程序。当然，这主要是需求一开始，感觉没这么复杂，随着运动项目不断的增多，个体存在差异，这些问题才会暴露。我们也是在不断的学习，实践中进步。
再看现在开发的SAAS生管软件，我从
要手工编写的代码较多，info类，声明业务类接口，实现业务类，因为info类，基本上对应数据库，但又不同于数据库表，一个表20，30个字段是正常的，而且每个字段的类型往往有时不明确，不得已都要保留，如状态字段，状态的id和名称都要保留，在Convert时该补的在补上，当然这个Convert方法也要手工写的，因为字段多了，写的时候就要小心，不写漏写，只能每个字段比较看有没有少掉，开发过程中，看界面需求有没有少，少的话再补。因为整个解决方案项目较多，改完再调试执行，10分钟就过去了。
另外，我最担心的是数据访问层，因为用了EntityFramework，这个东西要用好，我估计没多少人。有时候，我看代码，感觉要完成一个info类的加载，不知要执行多少SQL语句。比如说一个订单的加载，可能要加载客户，业务员，付款方式。。。只要是外键关联的，可能都会加载，这无疑加重了数据库的负担。有时候，我看到程序，EntityFramework里是加载的对象，结果到了info类里又还原成id，感觉这里本末倒置。因为是新技术，所以感觉存在一定风险，一方面开发人员的学习成本，一方面开发效率。遇到技术问题，可能会迷失方向。
我心目中理想的方案，一定要有缓存，一定要尽量减少数据库的查询执行次数。只有做到这2点，才能满足大的访问量，不然访问量一大，一定会把数据库拖死，再强大的服务器也满足不了需求。因为有了缓存，许多实体数据只要查一次，再调用只要从缓存取就行，不要再向数据库请求。估计淘宝的东西，连查询结果也会缓存一下的。数据库查询，能关联查询一次性搞定的，尽量一次性完成。
当然，这些只是我的个人看法。所以有时间，还是多读书，学习好框架，好的分析设计思想。
