分层与接口

最近浏览了一些网上对分层 、接口等概念的讨论。

想想这个问题也是我所接触到的一些团队，他们所一直困扰的问题，我觉得有必要整理一下思路。

这里所说的分层，是逻辑上的概念，和物理分层不搭界，也就是说，如果你的程序不做分布式，按照分层的设计思路，你也应该在你的代码级别上体现出逻辑分层的思想。

在CSLA里，一个业务对象自身就包含了持久层和逻辑层（CSLA里要细分层次的话，数下来蛮多的：UI、UI与客户端业务逻辑层的工作间层、客户端业务逻辑层、客户端与服务端的物理协议层、服务端业务逻辑层、服务端业务逻辑层与持久层的协议层、持久层、数据库，当然，开发人员的工作是写其中的客户端业务逻辑层、服务端业务逻辑层、持久层，其余CSLA基本已经帮你做好了）。在这些业务对象里，CSLA里是用模板的方式提供给你，使得你方便地在这些对象里实现了除UI之外其余的层。

如果你将物理分层和逻辑上的分层相混搅的话，会感觉CSLA实在是瞎胡闹，怎么能将几层的代码写在一个类里面呢。

如果你搞懂并遵循了CSLA给你提供的模板和框架，那么，设计、开发和后期的维护都是比较方便的，特别是维护，你知道问题会处在哪里，可以在哪个类的哪个代码块里找到。

说具体点，如果数据库某个表增加了一个字段，那么，系统要用到这个字段的话，业务逻辑层必然要做改动，相关的业务类要增加属性，以及对这些属性的操作函数，然后体现到UI上。这就是我们所说的，业务的改变，会从UI到后台的整个的修改，这是无法规避的事实，没有一个现成的方法能解决掉这个问题，你必须从UI改到后台。

这个问题的关键是，接口改变了！

分层的好处，是建立在接口稳定的基础之上的。在接口不变的状况下，每个层可以单独去修改自己的代码，这方便了团队的合作开发，只要大家确定好接口。

但如果是上面说的要加一个字段，并且要体现到UI层，你肯定要到每个层里去修改相应的代码，而对于接口，或者增加、或者修改。不管如何，接口是动了。

有人会想到这样的办法来解决问题：函数名和参数都是固定的，然后，用一个自定义格式的合并字符串来提交数据和返回数据。例如像下面的案例：

存储过程这么写：

CREATE or REPLACE PROCEDURE TEST_P(
  I_PARM IN LONG,
  I_VALUE IN LONG,
  O_PARM OUT LONG,
  O_VALUE OUT LONG)
IS
BEGIN
  O_PARM := I_PARM;
  O_VALUE := I_VALUE;
END TEST_P;

I_PARM和I_VALUE是输入的参数集合，I_PARM里用#2分隔参数名，I_VALUE里用#2分隔参数值；

O_PARM和O_VALUE是输