构建 Silverlight 企业应用程序时的冒险 - 第 20 部分

这篇文章是关于代码生成的一些不太技术性（又名功能性）的内容，尤其是在使用 XAML 时，无论是 Silverlight 还是 WPF。这是一篇无代码文章，旨在为您在不同级别的代码生成规划提供一些思考。

基础知识

如果您参与了包含大量某种东西的应用程序，那么使用某种形式的代码生成可能是可行的。您可以将其用于许多目的，而且其中大多数（如果不是全部）已经完成。软件中一些常见的代码生成候选项包括：

• 业务对象
• 界面中的屏幕/窗口/表单
• 报告
• 数据库脚本

显然，还有更多。代码生成只有两个基本要求。您计划生成的内容必须以某种可以实际从代码块中提供的格式存在，并且您计划生成的内容必须具有某种重复性。

最常见要生成的是您的业务对象。它们往往非常重复，而且由于它们是以某种编程语言实现的，所以通常只需要生成简单的文本。如果您的应用程序基于某种关系数据库，您甚至可以利用数据库中的元数据作为生成业务对象的源。

设定目标

在考虑代码生成时，您应该做的第一件事就是设定目标。我的意思是，您应该不仅考虑要生成什么，还要考虑为什么。生成的代码仅仅是一个起点，而且您永远不会重新生成吗？或者您有兴趣在某个时候重新生成代码？您对这些问题的回答将对您的生成过程应该如何进行产生重大影响。

如果您只生成一次，您需要确保在生成过程中使用的任何元数据都是最终的。经验告诉我们，这几乎是不可能实现的，所以至少要确保更改的影响尽可能小，并确保生成的代码是可读的。

如果您要重新生成，请考虑这样一个事实：您不仅需要运行该过程并确保不会丢失对生成代码的任何自定义，还需要确保再次使用任何元数据源。稍后将对此进行更多介绍。重新生成时的另一个担忧是集成测试。当您重新生成应用程序源代码的某个部分时，您已经更改了所有源代码，很可能因此会发生某些错误。请确保您考虑如何至少测试故障，或者更好的是，如何首先防止故障。

要有业务案例

您可能需要在您的组织中推销代码生成，也可能不需要，但您应该始终为代码生成过程提供业务案例。我的意思是，您至少应该对构建生成过程需要多少精力以及最终节省多少时间有所了解。基本上，在投入大量时间之前，您至少需要自己进行一项投资回报率（ROI）计算。我知道一开始您可能觉得不会投入那么多，但请相信我，在您真正坐下来进行一个像样的估算之前，您很可能最终会花费两倍于您最初的预想的时间。

在审视这个业务案例时，请确保您不仅包含显而易见的内容。每个人都可以看出，不必编写特定数量的代码可以节省时间。经常被忽略的是生成代码的质量。它是一致的，这意味着您可以测试一个代码实例，并且知道其余的代码也会正常工作。这也意味着可以减少 bug 的数量，如果生成的代码中发现了 bug，可以减少修复这些 bug 所需的精力。

我曾在不同的角色在多家软件公司工作过，经验告诉我，减少 bug 比节省编写代码的成本更重要。 bug 的出现不仅会造成金钱损失，还会影响声誉和客户满意度。减少 bug 对每个人都有好处。

棘手的情况

显然，您不可能生成应用程序中的每一行代码，但是我们大多数人在某个时候都会忍不住尝试生成一些过于困难的东西。要生成的最被低估的代码部分之一是 GUI。

假设您正在构建一个有 100 个表单的业务应用程序，这些表单都用于数据录入。这显然是一个非常常见的情况。没有多少开发人员喜欢去构建如此多的表单。当你的工作就是自动化重复性任务时，做重复性工作感觉很愚蠢。

然而，这里面还有更多需要考虑的。假设您想为 Silverlight 应用程序执行此操作。乍一看，您需要为每个表单生成一些 XAML，其中需要包含一些 TextBlock 来显示标签，以及一些其他控件用于输入。到目前为止一切看起来都很好。

现在考虑您实际上生成这些所需的元数据。您可能会说您已经有了，因为它与您用于生成业务对象的元数据相同。是吗？我对此表示怀疑。您的业务对象告诉您的唯一信息是它包含哪些字段以及它们的类型。它们没有告诉您关于表单中位置的任何信息。也没有关于某个特定控件需要与大多数其他控件不同的任何特殊行为的信息。

所有这些额外的信息都需要来自功能设计师，可能是某个应用程序专家，甚至是团队中的一名开发人员。现在，假设您已经以某种可用形式获得了这些元数据。您仍然无法生成功能完整的表单。现在您需要绑定到您的业务对象。起初，这并不难，但当您的数据模型发展或功能设计师决定将某个字段从同一表单上的另一个业务对象链接进来时，事情就开始变得复杂了，因为这对用户来说更方便。

现在，假设您甚至已经控制了这一点。现在您仍然需要输入行为。您需要附加事件，这意味着您还需要生成应用程序的后台代码，但您也希望将来能够扩展后台代码。该过程所需的元数据必须在某个时候来自开发人员。

如果您现在放眼生成 XAML 表单的整体图景，您将有三个元数据来源，而不是一个：

• 数据模型
• 功能设计师
• 开发人员

这三种信息来源需要整合起来，以便在单个生成过程中使用。构建这样的东西很快就会变成一个独立的工程项目，而不是一个简单的实现手段。

换位思考

那么，您是否应该这样做？这是一个好问题，没有简单的“是”或“否”的答案。这完全取决于您之前的 ROI 计算。构建和实现这种构建 GUI 的方法需要多少精力？以及有多少精力可以摆脱传统的构建和维护方式？

显然，如果您有一个非常大的应用程序，这可能确实有效，但另一种有效的情况是如果您是“一人秀”。如果您负责数据模型、功能设计和应用程序开发，那么这可能就值得付出努力。原因是您控制了所有变量，而且没有团队需要顾及如何与此协作。

那么，如果您发现这种方法不适合您的项目，您是否应该手动构建一百个表单？好吧，没那么快。如果您可以消除一个或两个信息来源（通过不生成那部分代码，或者至少不在同一组件中生成），您或许就能使其可行。要记住的是，组合元数据来源会使事情变得更复杂，所以尽量将它们分开。

我希望这篇文章能帮助您在是否生成应用程序代码的特定部分做出选择。如果您有任何问题、评论等，您懂得该怎么做。