如何处理支付类型与最优雅的方式不同性质

Question

我使用ASP.NET MVC 2

保持简单，我有三个支付类型：信用卡，E-检查，或“稍后给我开账单”。我想：

1. 选择一个支付类型
2. 显示为一个支付类型的一些领域在我看来
3. 运行一些逻辑使用这些字段（特定类型）
4. 显示一个确认视图
5. 运行使用这些字段（特定于类型）
6. 显示收据视图一些更多的逻辑

每种支付类型都有特定的字段类型......也许有2个字段，也许更多。现在，我知道有多少种和哪些领域，但是可以添加更多。我认为对我的观点来说最好的办法是对每个支付类型进行局部视图以处理不同的字段，并让控制器决定要呈现哪个部分（如果您有更好的选择，我会打开）。我真正的问题来自视图之间控制器中发生的逻辑。每种付款类型都有可变数量的字段。我想保留所有强类型的内容，但感觉像某种字典是唯一的选择。添加到根据付款类型运行的特定逻辑。

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

这不是优雅的解决方案，感觉非常错误。我伸出手来。你会如何做到这一点？

Answer 1

这是一个事情，比如说，一个Order对象不关心具体的付款方式 - 只知道有一个PledgedAmount和DepositedAmount特性，例如，是足以让这个类来完成其工作（例如，“如果订单不收费，请不要让我自己进入发货状态，通过任何付款方式，我都不在乎，只要收到某种方式我就很酷”）。

UI的另一件事是不真正在意：你要么编写一个switch来加载正确的视图并完成它，要么最终创建一个类似字典的字段，规则和验证元数据的集合，以及让UI动态生成自己。

例如，当我为我的某个应用程序添加国际地址支持时，我采用了后一种方法。我将地址抽象为一组常用的字段：AdministrativeArea，Municipality等，并定义了一个AddressScheme类，它为每个字段定义了AddressFieldRule s，说明是否需要，是否应该应用正则表达式，是否存在特定集允许的值等。这是适当的，因为我们可以随时在允许的列表中添加或删除国家，而无需重新编译和重新部署应用程序; UI可以根据自己从数据库加载的AddressScheme自动生成。甜。

但是，你真的要增加支付类型（a），或者（b）不用重新编译你的应用程序？有时候你真的需要一台真正的烤面包机而不是一台含早餐面包和其他基于酵母的食品烘焙模块的早餐烹饪机，所以只需添加一个开关或字典，将类型映射到正确的视图：我认为这是完全可以接受的用户界面必须能够区分这些类型，更重要的是，您可以自定义编写和调整每种类型的表示 - 但较高级的部分可能会从某些抽象中受益。 I talked about that in my answer to a different question related to billing.

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

我的两分钱。祝你好运！

Answer 2

听起来您有三种不同的工作流程，每种工作流程都与用户选择的不同付款方式有关。虽然您只明确指出步骤3和步骤5具有付款特定问题，但似乎在步骤1之后的所有内容都必须显示付款的具体信息（除非在步骤4中用户没有确认付款的具体信息，并且在步骤6中他们的收据不会不表示他们如何支付）。

在这种情况下，您可能会为自己创建一个更大的混乱，试图将所有这些组合到一个工作流程中，而不是为每种付款类型创建不同的控制器，并将任何常见行为分解为三个路径。

另外，虽然你表示你没有使用界面，但你给出的理由似乎有点麻烦。听起来好像您可能已经使用了界面，如果付款类型包含相同的字段。接口用于定义行为契约，所以你不应该使用它们来定义公共数据。