使用经典的asp，多年来我们开发了一个框架来处理一些相当复杂的web crud页面。
crud类被设计为某种“有限状态机”
使用隐藏字段在帖子之间保留状态，并且页面上的每个事件都会引发具有特定操作的帖子。根据触发的动作和之前的状态，crud类执行某些操作（如运行查询，保存记录，编辑记录等等），然后进入另一个状态。
这些是我们目前处理的一些州
查询：允许用户输入查询条件以过滤数据。
browse：以表格形式显示数据。与分页，订购等...
新的，编辑，删除：嗯，很明显
browse-single：喜欢编辑但只读
等...
为了实现所需的功能，我们保留隐藏的文本信息，如： 实际操作，实际模式，上一个操作，上一个模式，所选记录的ID，订单标准等...
现在我们已经实现了一些主从功能，但这种方法有点过于复杂。
我们必须在隐藏字段中保留父记录的id，父字段，父模式，子模式，当前选项卡，上一个选项卡（我们将信息分成几个选项卡）。 ..
当您必须处理“自定义”操作（例如批准发票）或警告，错误，自定义“工作流程”以及类似的事情时，事情变得更加复杂......最后我们看到，一旦我们偏离标准的粗略案例，这种方法就会变得太复杂......
您如何看待这种方法？
你如何处理这类事情？
你可以建议我看看的任何模式吗？
如何跟踪表单的状态？
答案 0 :(得分：1)
这听起来很合理。
听起来你的所有代码之间都有紧密耦合，所以当你偏离标准模式时，它就不能正常工作。您可以考虑将其分解为多个层。拥有图层会将问题分开，以便您可以替换它的一部分，而不是另一部分。
找出你需要灵活性的地方：
我曾经建立过类似的东西。它会自动为任何实体构建CRUD行为。但是，如果您想要预览行为或者有一些奇怪的编辑流程或不同情况下的不同视图，您可以覆盖控件中的任何操作。它是通过覆盖基类来完成的。您可以创建自己的高级字段列表来控制字段的顺序和外观。或者你可以创建一个低级表单，替换所有标准的东西，并控制给定表单的所有显示。
你也可以看看Rails Active Scaffold,（是的，我知道不是ASP），它以类似的方式解决问题，提供了几个扩展点。
答案 1 :(得分：1)
我自己也使用过这种方法并且非常成功。
这是实现可扩展性的最简单方法之一 轻松平衡多台服务器。但是，除非您更新 数据库上的每个动作都可以轻易丢失用户输入。哪里 交易很复杂，包括几个屏幕和表格 很容易让你的数据库处于不一致的状态。
可能的做法是将数据存储在浏览器cookie中 所以他们不是那么可见。
另一种方法是通过会话在服务器上存储所有内容 方（ala Spring框架）。这使得整个事情变得更加安全 因为恶意脚本没有与密钥一起玩的机会 和状态值，但是，在高流量站点存储和检索 会话状态很快变成瓶颈，并且在负载均衡的站点中 您需要将用户会话与特定服务器绑定。
重要的解决方案是将会话数据存储在数据库中 所以很容易从几个服务器上获得。
对于复杂的更新，您还可以考虑从CRUD模式转移到更多模式 复杂的WorkFlow模式。 在工作流模式中，您可以将用户输入更多地视为a 传统形式（认为多节税表与附录等）必须通过几个过程（创建，验证， 批准，等等。在行动之前。
您可以将输入存储为具有所请求的相当复杂的xml 更新和当前状态。可以存储多个表的更新 在单个xml中，并且，仅在所有更改之后的最后阶段 已输入，验证和确认更新的基础表。 您将屏幕与每个状态相关联，用户操作在屏幕上 像经典的有限状态机那样导致新的状态。
这种方法的一大优点是“形式”与之相关联 用户而不是会话，因此，可以输入和编辑输入 几天的许多会议（这也可能被认为是一个劣势！）。