接口问题

 最近有个争论，就是视图到底怎么写才更有可扩展性？

有两种写法：

1，select 。。。，GetName（CD） name from AA；语句中GetName是一个带返回值的存储过程

2，select 。。。，BB.name name from AA join BB。。。；

其中一方认为第一种写法更具可扩展性？！

我们来分析下。

首先排除掉物理部署上的可扩展性问题，也就是说到底是采取写在应用服务层上还是写在数据库里？当然，前者比后者可能稍微麻烦点（这要看部署策略和维护策略）；那么，剩下的就是代码编写和维护层面上的可扩展性问题；

首先，我们判断业务逻辑的更改会不会造成可扩展性问题？

一种情况，是数据结构的改变而且涉及业务逻辑，比如需要增加一个字段（不涉及业务逻辑的例子：增加个备注字段，仅仅是输入输出，框架从技术层面也能自动解决这样的升级而无须编写业务代码），这个字段还要经过业务逻辑代码的处理，那么，必然要改变各个业务逻辑层之间的接口，为什么？业务逻辑层之间不管采取什么形式，都是调用和被调用的关系，参数的发送和接受都需要对传递的信息进行打包和解析，对于业务代码来说，一定要清楚参数的含义，也就是显式的处理代码。那么这种改变造成的代码修改是不可避免的，尽管框架可以在层与层之间做些传递上的自动化处理（比如Packer和CSLA的做法）。对于前面的例子来说，就是SQL语句中增加了一个字段，视图要改写，视图的调用方也得改写。

另一种情况，是业务逻辑的处理方法发生了改变，对于前面的例子来说，就是GetName里面的处理方法发生了改变。那么，只要参数定义（例子中是别名name）不变，对于调用方来说，确实没任何影响（至于调用方是否要对新的name值进行新的方法处理，那是另外回事，不影响对此SQL可扩展性的分析），也就是说，在接口（本例是视图名、字段名、字段类型）不变的情况下，可扩展性问题被局限在了一定范围内。

既然我们把接口定义好了，可扩展性问题就仅仅是一个SQL内部的事情，这就简单多了。

试问，一个存储过程与一个关联表SQL之间，其编写难度、复杂度、代码量、维护量、维护难度，哪个更大？

在我看来，区别仅在于后一种方法把业务逻辑暴露在了VIEW里面。

可扩展性是蛮重要的，但是对于一个系统来说，不仅仅是这一方面要考虑的问题，它是权衡利弊下的产物，恩，效率有时候更加重要，因为这是用户最切身体会的方面。

题外话：是否采用存储过程，更多的应该从可重用性来考虑。