关于多层结构部属的问题

道听途说之后，为了分层而分层，往往令人烦恼。

那本OA书我在一个朋友那里看到过，简单一翻，就知道跟作者一年多前打工时写的OA代码一样，没有什么架构概念，沙丘上的碉堡，好看不好用。照着那种东西写出来的东西笨笨的，上手快但是很长时期也搞不出适应用户业务使用的可灵活修改的交互性系统。

为什么分层？是为了真正节省劳动。实际上，你只需要在业务对象的类型定义上定义一些属性，数据库就给你自动创建了或者升级/更新了，同样只要在类型或者类中方法、属性上说明一下，界面就能自动给你创建了。例如你设计控件的时候只要声明以下属性，设计器上的属性编辑界面就会自动根据你的要求生成不同的辅助操作画面。那种把一些数据库操作的公共函数封装在一起的，根本不能叫做数据层，那纯粹是很原始的过程库概念。因为所有业务系统中都有数据库操作代码，把他们有效剥离出来，使得程序员几乎不用去过程性编码而只需要针对目的进行声明就能自动生成有关的代码，这个完整的系统才叫做数据库层。对于UI层也是这样，传递给一个页面一个业务对象，这也页面根据业务对象自动找出合适的UI控件显示它，例如如果是主表——明细表结构的业务数据会自动解释生成带有明细录入和汇总等丰富内容的画面，完成这个功能的系统才叫做 UI层。把一些琐碎的底层代码拼凑起来，程序员写业务处理过程的时候还是要大量写过程化的代码来处理调用这些琐碎的代码片断，这就让人怀疑所谓的分层到底有多大的作用了。

所以我比较强调开发组织要创造工具，少为了教条而单纯在口号上去约束程序员。一个中小型mis系统可能有七、八十个业务类型、两三百个页面，其实UI表现形式只有五六种，如果在声明业务类型的时候用一句代码声明一下UI类型就行了，程序员肯定不会去费力气一个一个业务类型去去写单独的页面。你有现成的工具，能够提高效率十倍，不信他不遵循。