【IT168 专稿】无论是系统架构师还是普通程序员在构建应用程序时都期望系统的业务逻辑层构建得灵活而易于维护。因此，尽可能消除代码重复几乎成为传统软件开发过程中的金科玉律。为此，人们付出巨大的努力，包括投入大量的时间来研究如何设计出适当的模式以适合开发需求。当然，视选择的开发平台的不同，人们为之付出的努力程度也存在不同程度的差异。

　　微软于2008年正式推出的ASP.NET MVC框架正是适合上述需求的平台之一。借助于这个框架，我们得以能够最小的努力来创建灵活和易于维护的应用程序。特别是，它还提供的功能能够帮助我们最大程度地避免代码重复。

　　在本文中，我们将构建一个简单的新用户注册的ASP.NET 3.5 Web网站示例。通过这个例子，我们的主旨在于探讨如何能够通过把ASP.NET MVC框架和微软Windows工作流(Windows Workflow Foundation)架构结合到一起来开发出极富弹性的用户界面型工作流应用程序。具体地说，此示例应用程序将演示如何避免校验逻辑以及如何最大程度地实现应用程序本身与工作流业务逻辑部分的解耦。

　　一 数据持久性考虑

　　在编写多步骤用户界面工作流程应用程序方面，存在多种可选方案可用于实现用户输入数据的持久性存储。下面给出了多种可选方案的列表，以及它们各自存在的优缺点。

　　方案1  把每个步骤中的数据存储到服务器端数据库中。

　　优点：如果用户在操作过程中因为某种中断(可能因连接掉线或浏览器崩溃等原因所致)突然离开，那么，在下次回来时他还可以继续之前的操作—这将明显地提高系统的可靠性。【注意】这种方案的一个局限性是，通常这种类型的方法需要使用由客户端会话ID或MAC地址构造的Cookie结构。然而，如果用户下一次从另一台不同的机器访问网站时，他将无法继续操作。对此，我们有一种解决方法是，在第一步中就要求用户提供凭证数据—我们可以使用此数据来识别用户的下一次系统进入。

　　缺点：①在正式提交前耗费服务器内存存储用户不必要的数据—有可能需要定期刷新数据库中储存的数据，以防用户永远不会回来;②需要服务器回寄支持(但我们可以通过AJAX调用来克服之)。

　　方案2  在浏览器会话(Session)中存储每个步骤的数据，成功验证后，最后再一起储存到服务器端数据库中。

　　优点：由于数据没有存储到数据库中，所以不必要创建独立的进程实现一次性存储所有不必要的数据。

　　缺点：①提高了服务器端内存消耗;②在用户不启用会话(多种原因：浏览器崩溃，会话超时，应用程序池循环利用等)时导致不可靠性。

　　方案3  先序列化页面的数据，成功验证后，最后再一起存储到服务器端数据库中。

　　优点：由于数据没有存储到后台数据库中，所以不必要创建独立的进程实现一次性存储所有不必要的数据。

　　缺点：单个网页的尺寸可能会因之急剧膨胀，因而会影响系统的响应时间。

　　方案4  在同一个页面中的多个面板(对于jQuery框架来是指Div元素)中存储每个步骤的数据，成功验证后，最后再一起存储存到数据库中。

　　优点：①用户界面响应性能好;②不需要服务器回寄，因而最有利于提高服务器资源和数据库的利用率。

　　缺点：①在客户端浏览器崩溃时用户并不总是有释放数据的机会;②重新安排页面顺序以及改变相应的操作流程的可能性很小。

　　值得注意的是，选择上述任何方案之一最终还将取决于系统功能和具体的业务逻辑需求。本文中将构建的示例应用程序将采取上表中的第3种存储方案。

　　本文中将构建的示例应用程序极其简单—它将展示一个简单的使用三个步骤的界面来实现新雇员注册的工作流程。

　　二 模型绑定

　　模型绑定是ASP.NET MVC框架提供的极其强大的可定制功能。借助于模型绑定，在HTTP请求中传入的数据将被自动填充到模型类中。作为开发人员，我们没有必要担心提取Forms集合或querystring中数值所可能需要付出的大量编码的任务。基本上，存在两种类型的模型绑定支持：显式绑定和隐式绑定。通过调用TryUpdateModel方法，我们可以显式地触发绑定过程。通过把动作(Action)方法的参数设置为与模型类属性一样的名字，或通过把模型类自身作为动作(Action)方法的参数，我们可以隐式地取得HTTP请求中提供的数值并使之可用。

　　在本文示例应用程序中，“Employee”承担模型类的任务。我们在OnActionExecuting事件中调用了TryUpdateModel方法，以便Employee模型类对象能够使用用户输入的数据得以自动填充。