我正在开发一个应用程序，它有大量的相关表单数据需要处理。我正在使用MVC结构，并且所有相关数据都在我的模型中进行表示，以及从表单提交中处理数据验证。我正在寻找一些关于如何布置我的控制器的建议 - 基本上，我将拥有一个巨大的表单，该表单将被分解为可管理的类别（类似于信用卡应用程序），用户通过每个阶段/类别填写答案。所有这些形式类别都与主要关系/对象有关，但不与对方相关。表单MVC设计问题
将每个子窗体/类别作为主控制器类中的方法（这将使得一个控制器相当庞大）是否更有意义，还是最好将每个类别分解为主控制器的子类？第二种方法可能更好一些，但我很努力地看到为每个类别创建一个新方法（与模型进行通信并输出错误/成功）或创建一个新的控制器以处理相同的功能。
在此先感谢您的任何指导！
我的选择是为每个显示给用户的表单创建三元组Form-Controller-Model。无论何时用户点击表单上的“下一步”按钮，其控制器都应与后端管理器通话，后者负责将提交请求分发给链中的下一个表单。如果单击“返回”按钮，则为副诗。最后一个表格有一个'完成'按钮，它将转到管理员并传递最后一部分信息。
这将避免继承，使您的代码更健壮并且可以单独测试表单。
我的首选是将它全部保存在一个控制器中。它保留了在一个地方填写申请/表格的所有相关流程，但我不确定您所谈论的是多么“大规模”。如果你决定拆分它，我不会从主控制器中分类出来，而只是制造一些独立的控制器，或许与名称相关，以便于在路上使用。
谢谢瑞恩。大规模可能是一种夸张，但可能会有大约10种类别/方法，所以我开始对这种设计是否糟糕感到不安，因为将所有这些存储在一个控制器中 - 但正如您所说，它确实有意义，因为它是一种形式的所有部分 – kenny99 2010-03-24 15:48:23
控制器旨在处理一件“事情”的工作 - 您想如何定义由您决定的粒度。对两个方向都有利弊，但我不知道是否真的有正确或错误的走向。 – 2010-03-24 16:23:06
干杯鲍里斯，这种方法也是有道理的。我正在使用ORM，每个模型都代表一个数据库关系，但是，在每个类别/子表单中，我可能会与多个模型进行交互，那么您的方法在这种情况下是可行的吗？道歉，如果我误解了 – kenny99 2010-03-24 16:07:55
干杯肯尼，有模型和模型。 MVC的模型是支持视图状态的对象，即您的表单。您正在讨论的模型是栅栏业务逻辑端的域对象模型。这就像有一家商店。您将使用不同的成语向客户展示产品/服务，以及用于管理股票和融资的其他产品/服务。 – 2010-03-24 16:44:46