我开发的基本观点

1.作为架构,抽像是重要的,但是技术实现更重要,必竟有些性能问题不是光加机器可以解决的.比如松耦合,用队列最好,但队列需要数据库监听,分布式大量的数据传输,大量的序列化和反序列化都是性能瓶颈,异步需要大量的日志读写,多线程自身的损耗,负载匀衡自身的损耗,以消息机制还会导致数据库读写成倍的增长,而这以前很多数据可以存在页面上,或内存里.

2.同样,必须考虑到程序员的感受,window服务肯定没有exe文件好调试,remoting肯定没有wcf好用,添加一个小功能要写一大串代码,肯定会让人不满,比如,加一个功能,要改接口,加参数类,改配制文件.环境搭建复杂,又是服务,又是wcf,又是反射.全列队导致要分析大量日志,而分布式日志又写在不同的服务器上,无法快速定位问题,无法调试,环境难配.

3.要考虑到上线的难度,这时,各种集中配置,动态访问配置文件,配置文件的管理,上线是否要掉线等.

 

4.公司各部门的利益,各个人的利益平衡.就拿我们来说,始终不能比较完美的去做一件事,比如有一种新的架构,从别的部门那里有现成的代码,我认为其实可以利用先进的架构思想,做一套新的适合本部门业务习惯的代码框架,可是因为时间,因为人员,就直接把别的部门的代码拿过来,用的时候有诸多不适.怕是今后用的人也不多.各种思想不同一,而导致的代码差异.想学习的,想做实验的,想尽快干完的,想省事的.领导的立场和程序员的立场是不一样的,领导一般要求抽象,因为可以把系统了然于心,把所有逻辑写在按纽里,对领导来说,就是个黑盒.程序员则希望省时,省事,省心.好改,好调,好上线.

5.复杂的问题简单化,专业的问题通俗化.而现在则有一种感觉,简单的问题复杂化,通俗的问题专业化.我觉得不管是什么公司,一定会有把数据库代码写在页面上就能完事的应用.

设计模式没有优劣,只有适用场景,对于给中小企业做小项目的公司,把sql语句写在页面上是最为合适的开发方式.