软件的分层开发架构的另一种思考

在软件开发中，从事架构设计的人员往往都很推崇三层或多层架构，使数据库、业务和界面分离开发，而对于底层的开发人员来说，又多对此有很多抱怨，一方面是因为其所处角度及阅历不同，另一方面的原因也是真多了多层开发体系的一些弱点而言。
就两方的矛盾而言，其实也可以考虑这换个思路来利用三层架构。

首先，三层架构使界面层和业务层的编程人员不用考虑数据库的设置问题，而按照相应的需求自行开发，提高了多方协同工作的效率，从整体上加快了编程速度。

但任何并行化带来的实际是总体工作量的增加，而不是减少，包括接口设计、架构设计，代码组织等，但为什么会提高进度呢，根本原因是更大限度的提高了每个人的开发效率。

三层开发的另一个问题是软件的执行效率问题，直接写sql语句、连表查询、存储过程等的执行效率肯定比ORM要强，但是编程时为了可以实现调试往往显示功能第一，其次是效率。

那么我们就换个角度考虑问题。人们都看过冰雕，做冰雕的并不是一次将一个大方冰砖雕成美女，而是先做个轮廓，然后逐一去做细节，三层架构是一个很好的轮廓实现方法。在功能实现后，是可以在数据层增加特定接口或改写接口的实现方式的，这样我们就可以既保证了项目开发效率，又提高了软件执行效率。

在后期系统优化过程中，即使是面向过程编程，也需要通过分析各模块的执行速度来确定特定的优化方案，在此时引入特有的sql语句，并对数据层进行相应调整，也是非常合适的。从主要的优化工作看：

1. 运行速度优化： 提高系统运行的速度，一般运行速度慢的现象都是界面加载及更新慢，这里面原因有布局初始化、数据库存取、无效阻塞、软件BUG等很多因素。

2. 用户支持能力优化： 使系统可以支持更大的并发用户能力以及在更大规模的数据量情况保持系统速度， 此时我们往往采用异步处理、并行化、缓存系统等方式减少通信量、提高计算效率。

对于没有使用了分层开发的系统，在此过程的优化时，我们往往会因为在优化过程中担心方法调用的耦合性而放弃很多可以大幅度提醒性能的方式，而如果使用了分层开发，由于各组件中的耦合度相对较低，只需要进行组件内调整，不会对其他组件产生影响。

而对于数据库存取的优化，分层开发在此时的优化效率优势就更加明显， 因为面向过程开发时，不可避免会产生大量的重复功能SQL语句， 很难一次理清，而对于分层开发，可以使用统一的经优化的接口，一次优化直接对多个模块其作用。

在系统优化过程中，我们有时还会调整数据库的表结构， 这对面向过程开发往往会是灾难性的，因而会尽量避免，往往提高了优化难度，延长了时间，而分层开发可以以很小的代价就可以快速的实现相关优化。