问如何为不同的客户定制web应用程序(页面和用户界面)

EN

如果您的常规数据保存在数据库中，我不完全确定为什么要将所有特定于客户的信息保存在xml文件中。把它移到数据库里。

接下来，有很多不同类型的规则引擎。考虑到您使用的是asp.net，您可能需要查看Workflow至少其中的一些内容。您可以阅读以下内容：http://karlreinsch.com/2010/02/05/microsoft-rule-engines/

很久以前，我使用了一个叫做Haley的产品来驱动一个c#网络应用程序。它控制着从屏幕到出现的字段的所有东西，以及它们是否是必需的。花了一段时间让团队了解它是如何工作的，但是一旦它发生了，就会产生一个新的客户非常简单。海利从那时起就被甲骨文吞食了，但可能是绝对最好的。

其他您可能感兴趣的是NxBRE，甚至nCalc。NxBRE是一个实际的规则引擎，它是为java构建的一个端口。另一方面，nCalc本身并不是一个规则引擎。但是，如果您可以用简单的布尔语句来表示您的逻辑，那么它是非常快的。我目前正在使用这个来驱动我们的应用程序中的页面流。

一些商业产品包括：FlexRule，iLog

您现有的规则引擎工具支持您的web应用程序，这意味着它已经满足您的需要。您可以使用其他“规则引擎”，如MS工作流，但它也可以以一个难以维护的情况结束。

假设有注册门户网站。它收集一般用户信息并保存到数据库中。很简单。我们使用多个ASCX为一个客户端构建一个产品，为另一个客户机构建Rules.Then，我们为这些ASCX添加更多的规则和更多的控件。以这种方式工作，迟早我们会到达最后一根稻草客户。当时，代码库很难维护，开发人员在许多规则中迷失了自己。这就是我身上发生的事。

所以对我来说，这与使用哪个规则引擎无关。

那怎么做？

我提出了一个问题，其中一个回答对我来说是有意义的(认为不是一个经过挑选的答案)。在这个答案中，那个人提到了你是什么样的公司。在你的问题中，这更像是你是哪个部门，或者你想分开你的开发团队。

如果您是首席技术人员团队的成员，请使用规则引擎构建一个框架。创建一个基本的注册门户作为示例portal.Make DAO，BO与UI (分离层)解耦。

如果您是一个定制团队，创建自定义用户控件(不要在基本版本中重用这些用户控件)。您将重新创建的只是UI，您仍然可以使用DAO、BO，因为它们不是在用户控件中定义的，它们位于其他层。通过这种方式，您可以自由地定义客户端指定的规则，而不必担心污染其他客户端规则或在其他客户注册中引入新的bug。

只是意识到这不像是对你问题的回答。无论如何，这是我的想法后，有限的xp工作引擎规则为基础，多客户端的web应用程序。

当单个客户的需求大不相同以至于共享功能仅占给定客户需求功能的50%以下时，那么实际上只有两种主要的方法来处理这个问题：

为每个客户端

编写自定义页面

对于技术人员以及商业和销售人员来说，这有时都是一个令人不快的选择。如果客户端意识到您正在执行大量的自定义开发以满足他们的需求，这也可能令人不快。

技术考虑

作为一名开发人员，高可维护性是我们应该努力实现的核心目标之一，因此为单个客户编写自定义页面与此目标背道而驰。假设必须添加一个应该影响所有客户的公共功能，现在必须为所有客户端手动实现此更改，并对每个对该页面具有独立实现的客户端进行测试。如果你有很多客户，那么随着时间的推移，这可能是站不住脚的。

业务考虑事项

从作为ISV的业务角度来看，我们喜欢构建一个产品，它通常比软件本身所涉及的更多。销售软件产品意味着，作为一个供应商，我们有一个可以满足所有客户需求的包，只需对产品的核心进行最小到不定制。

当需要进行产品自定义以容纳客户时，产品可能是不合适的，或者只是计划得很差。也许，正在出售的解决方案实际上根本不能被认为是一种产品，而只是简单地以这种方式进行营销。软件业务可能会像这样棘手，这也是为什么产品所有者和销售人员赚大钱的原因，因为成功销售软件的成功公式可能非常棘手。如果你没有正确地营销它，或者正确地形成一个产品的概念，那么你可能不会销售，或者你可能会出售，并且无法兑现承诺。

客户端考虑事项

所有的客户都喜欢感觉自己得到了一笔很好的交易，当他们购买软件产品时，他们想要相信他们的所有需求都是现成的。这就是为什么软件产品比定制的软件开发更容易销售的原因，即使客户端的需求本质上是如此具体，以至于任何这样的产品都不可能存在。

如果客户发现您只为他们的需求执行了大量的定制软件开发，那么他们就不再相信您的产品曾经有能力交付，而且他们最终会为此付出高昂的代价来支付这些定制开发成本。

这是什么时候的好主意

？

如果该软件是在一个利基市场的少量客户和有限的增长机会，那么定制网页开发的具体功能可能是最好的选择。

基于

XML的布局和规则引擎

基本上，您将识别要构建到页面中的核心功能，任何特定于客户的功能都应该通过自定义布局和规则引擎来定义，该引擎允许客户端需要在代码库之外进行自定义。这方面的技术设计考虑是：

技术考虑

此时，客户端需要通过XML进行模式更改，而不是对代码更改进行昂贵的可维护性噩梦。通过XML来控制布局来定义您的视图，XML来绑定您的模型，以及定义您的控制器的规则将允许一个坚实的体系结构，它将随着您的业务的增长而扩展，并保持松散耦合、高内聚性和高可维护性。这些XML文档可以很容易地通过NoSQL或甚至传统的关系数据库系统维护。

业务考虑事项

限制有针对性的发布，以容纳客户，增强了整个产品的力量和可伸缩性，并使企业相信他们有能力在一个狂野和动荡的市场中快速增长。一些缺点是应用程序和产品本身的复杂性增加，以及对增加初始开发时间的考虑以及与此相关的更高成本。

客户端考虑事项

客户可以有信心，他们的需求是通过产品得到满足，没有明显的裁剪，他们的要求和变化可以迅速适应。