如何以最优雅的方式处理具有不同属性的付款类型

Question

我正在使用ASP.NET MVC 2。

为简单起见，我提供三种付款方式：信用卡，电子支票或“以后再付款”。 我想要：

1. 选择一种付款方式
2. 在我的视图中显示一种付款方式的一些字段
3. 使用这些字段（特定于类型）运行一些逻辑
4. 显示确认视图
5. 使用这些字段（特定于类型）运行更多逻辑
6. 显示收据视图

每个付款类型都有特定于该类型的字段...可能是2个字段，也许还有更多。 现在，我知道有多少个字段，但可以添加更多字段。 我认为，对我而言，最好的办法是为每种付款方式提供部分视图以处理不同的字段，并让控制器确定要呈现的部分视图（如果您有更好的选择，我会开放）。 我真正的问题来自视图之间控制器中发生的逻辑。 每种付款类型都有可变数量的字段。 我想保留所有类型的强类型，但是感觉只有某种字典是唯一的选择。 添加到根据付款类型运行的特定逻辑。

为了保持强类型，我为每种付款类型创建了一个类。 没有界面或继承的类型，因为每个付款类型的字段都不同。 然后，对于每种付款类型，我都有一个Submit（）方法。 然后，在控制器决定显示哪个局部视图的同时，它还分配了提交动作的目标。

这不是一个很好的解决方案，感觉很不对劲。 我正在伸出援手。 你会怎么做？

Answer 1

例如，对于Order对象来说，它并不真正在乎特定的付款类型是PledgedAmount -仅知道例如存在一个PledgedAmount和DepositedAmount属性就足以使该类完成其工作（例如，“如果通过任何付款方式都不收取订单费用，就不要让自己进入“已发货”状态，我并不介意，只要我以某种方式收取费用就可以了。”）

UI并不是很在乎另一件事：您编写了一个switch来加载正确的视图并完成操作，或者最终创建了类似字典的字段，规则和验证元数据集合，并让UI生成本身是动态的。

例如，当我为我的一个应用程序添加国际地址支持时，我采用了后一种方法。 我将地址抽象为一组通用字段： AdministrativeArea ， Municipality等，并定义了一个AddressScheme类，该类为每个字段定义了AddressFieldRule ，指出是否需要使用正则表达式，是否有特定的设置这是适当的，因为我们可以随时在允许列表中添加或删除国家/地区，而无需重新编译和重新部署应用程序； UI可以根据AddressScheme动态生成自身，而AddressScheme本身是从数据库中加载的。 甜。

但是，您是否真的要在不重新编译您的应用程序的情况下增加付款类型（a）或增加付款类型（b）？ 有时您确实确实需要一台真正的烤面包机，而不是一台带面包和其他基于酵母的商品褐变模块的早餐烹饪机，因此只需添加一个将类型映射到正确视图的开关或字典即可：我认为对于UI必须能够区分这些类型，更重要的是，您可以自定义编写和定制每种类型的表示形式-但较高的部分可能会受益于某些抽象。 我在回答与计费有关的另一个问题时谈到了这一点。

在您的示例中，您可以共享步骤1、4和6的通用代码，但可以委派给特定的UI方法和步骤2、3和5的视图。世界仍然会旋转。

我的两分钱。 祝好运！

Answer 2

听起来您有三个不同的工作流程，每个工作流程都与用户选择的不同付款方式有关。 尽管您仅将第3步和第5步明确表示为有特定付款问题，但似乎第1步之后的所有内容都必须显示特定付款信息（除非在第4步中，用户没有确认特定付款信息，而在第6步中，他们的收据没有不能说明他们的付款方式）。

在这种情况下，您可能会尝试将所有这些合并到一个工作流中，而不是为每种付款类型创建不同的控制器，从而排除任何常见行为，以供这三个路径重用，从而为自己造成更大的混乱。

顺便说一句，虽然您表示您没有使用接口，但给出的原因似乎有点令人不安。 如果付款类型包含相同的字段，听起来您可能使用了界面。 接口用于定义行为契约，因此您不应该使用它们来定义公共数据。