一个CEO日记-问题的一切
这是第二个计划是什么许多文章，涵盖的剪贴簿，设计和架构，和技术部门。虽然项目是如何构思的故事是很有趣，你也可以阅读有关的企业决策，技术的挑战和其他方面的考虑到产品设计。也有独立的组件，我们觉得社会会发现价值，我们将会提供技术讨论的代码。
以前的:如果你是刚刚通过本文，您可能希望先阅读以前的分期（S）:。简介
一旦精神的飞跃已经考虑创建一个新的平台，它是时间再考虑的目标，这个时候从更技术的角度。什么是主要的优先？虽然有很多事情，在新系统中的重要，明显突出的灵活性。需要有简单的方法来修改系统的几乎每一个方面。将高度的非技术用户进行一些简单的修改。
灵活定义在三个主要领域:数据模式的变化。标准业务逻辑的变化。屏幕布局和客户端的工作流程的变化。
为了实现这些目标，该系统的设计将开始用一张白纸。没有什么是神圣的或假定。的口头禅是"一切问题"。一个需要确定，并制定满足这一需要的最佳途径是。在一个反复的过程，新方法被应用到系统设计到这一点。如果需要额外的功能被添加到该基地，以支持新的功能，它增加了。这种结构的不断检讨。如果变得太令人费解的底层结构，一种新的机制是必要的，符合所有的复杂性没有确定的要求。虽然这听起来像一个笨拙的过程，有意识地努力用简单的组件，没有大量的内置功能。这导致了一个高度灵活的设计非常好，经受住了挑战。
利用XML
早日作出决定，利用XML来指定配置信息。 XML是非常灵活的，如果有点繁琐。它也是标准的大谈特谈。指定任何一个平台中立的方式，几乎意味着XML的这些日子。利用XML也允许使用其他工具进行编辑，验证和处理数据。文档中的图层
使用XML，"比较并合并"功能可以用来融入的基本文件的修改，这将是"图层"的变化。不止一个可用于层描述的含义，这是一个设计背后的推动力。
一个简单的例子，将有助于传达这个概念:
{S0}
处理所有的层和合并XML的复杂性，还需要额外的元数据。考虑，例如，在UI中的Tab键顺序通常是由反序列化的控制的顺序定义。这增加了一个XML的复杂性（没有双关语意）合并和整体架构和定义的各种文件和其层。架构定义
让数据模式的变化是相当简单的。提供一个"基础结构"的规范，然后提供额外增加的字段和表规格。
例如，让我们来看看一个简单的模式定义的元素在XML.lt;表名="Customerquot; GT; <字段名称="; IDquot / GT; <字段名称="; FirstNamequot / GT; <字段名称="; LastNamequot / GT;LT; / Tablegt;
如果想延长这种模式定义一个"层"，它会定义额外的字段（或去除/修改现有油田）:LT;表名="Customerquot; GT; <字段名称="; IsNewCustomerquot / GT;LT; / Tablegt;
然后，使用XML"的差异和合并"实用，应用程序的完整架构，包括所有的应用层，将建造。还允许参照完整性，默认值和更多的规格。这种方法是类似原来的产品。主要的变化是切换到XML规范。该XML锤变得太大
这与XML的迷恋导致我们的第一个"锤子和钉子"的时刻。由于有一个集成层的业务逻辑的要求，为什么不把在XML，以及？为了回答这个问题，必须确定XML实现，以及如何合并业务逻辑从其他层的功能。首先，XML不包含编译的代码。这意味着XML代码会被解释或编译的"飞行"。而后者则是可能的话，将远远超过已编译的代码的问题。早期的解释代码的经验非常好，作为一种替代淘汰。合并也是一个问题。 CVS和类似系统不谈，合并成代码的修改，是不是一个完美的科学。发现问题将是极其困难的。业务规则
加强的XML灾难的边缘，现在是时候重新审视一下修改业务逻辑需要完成。对于本次讨论的目的，业务逻辑的元素将被称为业务规则。业务规则需要输入（参数），对他们进行一些处理（以及与其他数据访问规则），并生成输出。关于修改业务逻辑时，第一个冲动是试图改变内部规则的过程。这是没有必要的的！业务规则本身是一个"黑盒子"。出现，东西出来。如果你想改变业务逻辑，你真的不希望改变的过程，你想改变过程中使用的输入或输出，它生成。如果你有能力做这两件事情，可以从根本上改变任何业务逻辑。
为了说明:
开发商熟悉面向方面的编程，将看到的AOP概念和这种体系结构之间的相似性。
的修改业务逻辑的目标有了新的认识，答案变得清晰。只要我们可以使用编译后的代码，因为它可以在运行时动态加载。我们需要的是添加新工艺的应用能力，并指定要运行时，的能力。这些新工艺，可完全新的业务规则，或者他们可能会修改现有规则的输入或输出逻辑。现在需要的是唯一的机制来调用编译规则，加的方式来传递参数和得到的结果。
虽然XML的方式来增加系统的业务规则，它实际上是一个伟大的方式来指定这些规则时，应运行。确定有四种类型的业务规则处决:规则专门推出一个客户端应用程序的命令。从其他规则内调用的规则。检测到触发事件时，会自动执行的规则。规则修改输入或其他规则的结果。
事实证明，第四起案件只是一个专门的情况下第三。业务规则需要加以查明，让他们可以执行的基础上配置设置，使一个对象将被用来确定和开展的业务规则。要修改输入或输出，一个"BeforeProcess"和"AfterProcess"事件将能够推出其他的规则，以使这些更改。现在所有层需要做的是确定的地方规则"火"。
在使用前和事件后的规则"，以覆盖业务逻辑，这是必要的，现有的规则尽可能为"原子"。这是说，每一个规则应该只能做一件事情。如果规则执行一个动作，然后使用内部行动的结果，在相同的规则，有没有机会重写的第一个动作或输入到第二个。再次，这是一个AOP的架构的宗旨，未能实现模块化，条块分割的业务规则的影响，毕竟系统的灵活性，这是它的主要目标，。虽然新系统无法执行的"原子"的业务规则的做法，这是肯定的建议。容器和数据对象
与有关业务规则解决的最后一个项目是如何传递信息和退出。业务规则参数
在软件中使用的方法，大多采取一系列参数，其中每一个特定类型的数据。然后，这些方法可能返回一个返回值的数据单件。不幸的是，被传递的参数和返回值的类型构成的方法"签名"，这使得它尴尬存储到这些函数的指针，并调用他们以标准的方式。业务规则的数据要求
的其他问题，是由新平台的灵活性推出，数据，业务规则的需求不明确界定。该规则可调用另一个，它有一个重写的过程，需要不需要任何及其相关规则的数据之前或之后。只有这样，才能确保每一个规则，它需要所有的数据是通过所有可用的数据。结算的方法是使用"数据容器"，将所有的数据，任何规则，可以使用任何业务规则的唯一参数，并通过该容器对象。结果将同样通过设置在容器中的值返回。
客户端的通信
加载业务规则的数据是重要的，并没有很大的开销。通讯客户端的数据，另一方面，可能涉及的开销很大。有些机制需要进行设计，将最大限度地减少服务器和客户端之间的网络流量。
因为没有在客户端上的业务逻辑基础上的分离，是这些"层"的规定，这是没有必要为客户端在服务器的数据容器中的所有数据。要限制传输的数据量，这是必要的，以确定哪些数据的客户利益。而要做到这一点，数据元素存储在一个对象中的数据，简单地称为"数据对象"容器。两个标志中的数据对象的坐标数据时，应转移。
客户端上的数据对象的功能几乎是相同的服务器上（相对确定何时需要更新）的，因此也是在客户端上创建一个数据容器。事实上，在实施中，客户端和服务器共享完全相同的基类。一个"IsDirty"标志表明，在此数据对象的值比在另一边的数据对象的值是不同的。同伴"ClientAware"标志标识需要在客户端服务器上的数据对象。每次在数据对象中的值的变化，"IsDirty"标志设置。始终从客户端发起的通信。当客户端的接触服务器，建立一个"命令包"告诉服务器该怎么做。
这个过程的第一部分是检查数据容器，并放置到每个数据对象的新值被改变的数据包。那么脏的标志被清除。在服务器端，一旦完成与处理，它会遵循相同的程序，但只有将项目添加到响应数据包，脏，知道客户端。这样，每一方都不断与其他同步，但仅将更改的数据传输。业务规则的重新审视
集装箱实际设计（大多工作）之前，一些业务规则的其他要求充实。到目前为止，这些决定都是相对简单的，但是，他们推出了全一系列需要解决的问题，新:业务规则将如何确定？在容器中的数据将如何确定？如何将客户端的请求，业务规则的运行？哪些事件应触发自动业务规则呢？
这些问题的答案，将极大地影响了与客户的沟通。背后的那部分的拼图概念也变得更清晰，但它会采取几个传递到达一个满意的解决方案。
进一步讨论这些问题将在下一期中，即将举行的。
