2

我正在为一本杂志开发一个网络应用程序，该应用程序允许用户在线登录和更新他们的订阅。这些订阅是根据一组规则续订的，我想就如何设置这些规则获得一些想法/建议。

此 Web 应用程序与具有订阅者数据的外部（第三方）系统交互。当订阅者登录时，Web 应用程序会从这个第三方系统中获取大量信息，包括一个称为“订阅定义 ID”的数字，它（表面上）表示订阅者拥有的订阅类型。这种订阅类型可能已经过时了几年，因此 Web 应用程序包含一组“订单规范”（存储在数据库中），其中包含当前订阅选项以及当前费率等信息（因此价格可以在订购单上显示给用户）。

我目前的想法是创建一个订阅定义 ID 表，该表映射到给定订阅定义 ID 更新到的订单规范。例如，订阅定义 ID 可能表示十年前的 1 年订阅，当时的价格为 39.99 美元；在数据库中，这将映射到当前订单规格，当前价格为 59.99 美元。

这在理论上工作得很好，但像往常一样，有一个问题。当年设置订阅定义 ID 时，它们并不总是唯一的。特别是，一个订阅定义 ID 具有完全不同的行为，具体取决于上下文。此订阅定义 ID 用于 1 年订阅和 1 年折扣礼品订阅。因此，给定此订阅定义 ID，可能会发生许多事情：

  1. 如果是 1 年订阅，他将使用（当前）1 年订阅进行续订。
  2. 如果它是 1 年折扣礼品订阅并且订阅者没有续订任何其他订阅，它将作为（当前）1 年全价礼品订阅续订。
  3. 如果它是 1 年折扣礼品订阅并且订阅者正在续订其他订阅，则它将作为（当前）1 年折扣礼品订阅进行续订。

我不确定如何在数据库中概括这一点，特别是因为这种复杂情况只发生在一条记录上。我基本上需要一种方法来对上述逻辑进行建模，该方法也可以处理非特殊情况的记录。我总是可以在代码中执行此操作，但我不愿意将所有这些业务逻辑放在代码本身中（尤其是在将来出现问题的情况下，使用其他订阅定义 ID）。

对这种数据和逻辑规则组合进行建模的最佳方法是什么？

4

2 回答 2

0

这不是我通常会建议的，但是因为只有一个订阅定义 ID ，并且这种情况已经持续了很多年（因此这是一个稳定的业务规则），我建议对这个 ID 的行为进行硬编码.

于 2010-11-12T13:37:21.067 回答
0

这里的技巧是参数化业务逻辑，这意味着创建一个参数表。一般情况下，任何类型的订阅都有资格获得其他类型的续订，因此您有一个将原始订阅映射到符合条件的续订的表。然后，您将拥有检查用户订阅并显示 1 选项或续订选项列表的通用代码。

对于您的大多数情况，如果我理解您的意思，原始订阅只会映射到自身。您只有一种情况，其中一些订阅映射到特殊情况。

但是，如果您这样做，您将拥有一个很好的通用更新系统，该系统现在处于管理员的控制之下，因为他们可以修改映射而无需等待您提供新代码。

于 2011-01-20T14:31:51.307 回答