如何进行界面和业务逻辑分开的原型化开发

0 原型化开发的特定应用场合

由于生命周期法严格分阶段进行，按步就班，使整个开发工作有条不紊，因此便于开发工作的组织和管理，同时也大大降低了管理信息系统开发的复杂性。国内外的一些开发实例都证明了生命周期法是管理信息系统开发的一种行之有效的方法。
然而，在管理信息系统的长期开发实践中，也暴露了生命周期法的许多缺陷。首先是文档编写的工作量大，在生命周期法的每个开发阶段中都必须编写相应的文档。其次是开发过程的可见性差，来自最终用户的反馈太迟。在生命周期法的前面几阶段包括总体规划、系统分析和系统设计阶段，都不能在管理信息系统的用户终端显示新系统的实际效果。一直要等到系统实施阶段结束，用户才有可能从屏幕上见到新系统，也只有这时，用户才有可能通过对系统的试用来提出他们的建议和意见，但是此时整个开发工作己近尾声，若想修改前几阶段的工作成果将付出较大的人力和物力。为此，人们设法寻求一种新的系统开发方法，在这种情况下，“原型化” 技术应运而生。
随着计算机软件技术与系统开发工具的迅速发展，使得系统开发尤其是系统设计与实施工作越来越方便，从而对系统进行局部性修改或重新开发的代价大幅度下降，系统实施过程的自动化程度也有所提高。于是人们考虑在不太清楚一个系统的全部要求的情况下，先建立一个称为该系统的“原型”的系统模型并在计算机上实现，其中包括主要的程序模块、数据结构(数据库)、屏幕格式，输入输出功能等项内容，然后利用此模型来进一步设计和实现最终系统。这里的原型指的是系统的一个早期可运行版本，它反映最终系统的部分重要功能和特征。所谓原型法，就是根据用户提出的需求，由用户与开发人员共同商定先解决其中的基本部分，设计一个初步的原型并在短期内实现，然后交用户试用，经过一段时间的运行后，根据用户意见对原型加以修改或扩充，产生一个新的原型版本，如此反复这个过程，从而形成一个相对稳定的、质量较高的系统。

1确定界面和业务分工

（0）为什么要分工 分工的好处已经有很多文献讨论过，这里只强调并呼应文章开头所说的情形，要在用户和开发人员还不知道目标系统的全貌的情况下有一个可以试用的雏形。这个雏形应该包含用户已经提交的需求的部分或全部的输入界面，功能对应的“按钮”（不一定是button控件，而是泛指用户通过键盘鼠标发出指令的触发控件事件）。于是就产生了快速开发界面，而逻辑处理滞后的情形——这就是本文要讨论的界面开发和业务开发分开的需要所在。

（1）界面做些什么 界面应该只完成以下事情：a.给客户展现外观效果，b.数据文字的编排显示，c.可用功能的点击入口。

（2）业务做些什么 业务是完成数据处理和业务流程等工作的。如果界面和业务比较含糊的情况下，应该都有业务层完成。例如改变字体颜色。在许多情况下，它归属于界面，但是对于“用红色字体表示紧急情况”的功能来说，它应该是业务应该做的事情。所以，业务层完成：a.界面层未完成的事情作为他的首要任务，b.处理数据，c.向数据库（存储层）传递经过逻辑判断和处理的数据，d.决定何时请求数据，处理所请求的数据并以合适的格式传递给界面，e.控制界面的转换。

（3）层之间的传递 界面和业务逻辑分工的一个比较普遍的做法是，先把界面client的数据装入到内存数据结构dataClass中，然后再对内存数据结构dataClass的数据进行业务逻辑处理。

client <------> dataClass <-------> Database

这其中有很多可以进行一般性的抽象处理方法,进而大大减少代码量和使得维护工作方便、简单。而dataClass <-------> Database是ORM经常讨论的，已经有n多的解决方法，其中不乏成熟只作。

对于界面工程师, 专著于界面上的表现, 对于如何与逻辑部分交换/交互的代码, 应该越简单越好, 最好就是每个功能入口都格式简单且一致：

PenddingFunction((dobject)this,__FUNC__,L"待定功能",L"001",L"001");

于是，界面工程师就可以专著与效果表现，而对于逻辑则可以“不闻不问”。

2 在运行时确定和搜集用户需求

从上面讨论的格式简单且一致的入口开始，我们还有很多事情可以做。例如，如果逻辑还没有写，需求还不确定的情况下，在进入逻辑处理之前，增加一个对话框

例如搜集用户的流程图(Diagram)表达的意图.

或者文本需求(Text describe).

3 功能入口重定向

通过重新设定 class 的名字,方法的名字和参数值来重新指定实现代码入口, 可以使复杂的版本维护通过配置来维护实现指向.