【问题标题】:strategies / patterns for handling complex web crud forms?处理复杂的 web crud 表单的策略/模式?
【发布时间】:2009-09-17 05:05:17
【问题描述】:

使用经典的 asp,多年来我们开发了一个框架来处理一些相当复杂的 web crud 页面。

crud 类被设计成某种“有限状态机”

使用隐藏字段在帖子之间保留状态,页面上的每个事件都会引发具有特定操作的帖子。根据触发的动作和之前的状态,crud 类执行某些操作(如运行查询、保存记录、编辑记录等),然后进入另一个状态。

这些是我们目前正在处理的一些状态

query:让用户输入查询条件来过滤数据。

浏览:以表格形式显示数据。分页、排序等...

新建、编辑、删除:嗯,很明显

browse-single:类似编辑但只读

等等……

为了实现所需的功能,我们保留在隐藏文本信息中,例如: 实际动作、实际模式、上一个动作、上一个模式、所选记录的id、订单条件等...

现在我们已经实现了一些主从功能,但是这种方法有点太复杂了。

我们必须在隐藏字段中保留父记录的 id、父字段、父模式、子模式、当前选项卡、上一个选项卡(我们将信息分为几个选项卡)。 ..

当您必须处理“自定义”操作(如批准发票)或警告、错误、自定义“工作流程”等类似的事情时,事情会变得更加复杂......

最后我们看到,一旦我们偏离标准的 crud 案例,使用这种方法,事情就会变得过于复杂......

您如何看待这种方法?

你如何处理这些事情?

你能建议我看什么模式吗?

您如何跟踪表单的状态?

【问题讨论】:

    标签: design-patterns asp-classic webforms


    【解决方案1】:

    这听起来很合理。

    听起来您的所有代码之间存在紧密耦合,因此当您偏离标准模式时,它无法正常工作。您可以考虑将其分解为层。拥有层将分离出关注点,以便您可以替换其中的一部分,但不能替换另一部分。

    找出你需要灵活性的地方:

    • 如果您需要灵活地显示表单,您可以查找一个表单文件,如果没有,请使用您的默认设置。因此,您可以弄清楚如何以合理的方式覆盖表单。
    • 或者表单可能很好,但是对于某些实体,您需要稍微不同的流程(编辑后的预览)。弄清楚如何覆盖这个控制器逻辑。

    我曾经做过类似的事情。它会自动为任何实体构建 CRUD 行为。但是,如果您想要预览行为或有一些奇怪的编辑流程或针对不同情况的不同视图,您可以覆盖控制器中的任何操作。它是通过覆盖基类来完成的。您可以创建自己的高级字段列表来控制字段的顺序和外观。或者您可以创建一个低级表单,替换所有标准内容,并控制给定表单的所有显示。

    您还可以查看 Rails Active Scaffold,(是的,我不知道 ASP),它以类似的方式解决问题,提供了几个扩展点。

    【讨论】:

    • 是的,问题出在流程上(类不会生成整个表单,布局是用asp / html指定的),你的就是一个很好的例子,一个“预览”模式,或一些特定的流程。我必须找到一种方法来模拟经典 asp 中的“继承”,或者其他方式来自定义类的行为......
    【解决方案2】:

    我自己也使用过这种方法并且非常成功。

    这是实现可扩展性的最简单方法之一 轻松平衡多台服务器。但是,除非您更新 数据库上的每一个动作很容易丢失用户输入。在哪里 事务很复杂,涉及您的多个屏幕和表格 可以很容易地使您的数据库处于不一致的状态。

    对此的一种可能变化是将数据存储在浏览器 cookie 中 所以它们不太明显。

    另一种选择是通过会话将所有内容存储在服务器上 侧(ala Spring 框架)。这使整个事情更加安全 因为恶意脚本没有机会使用密钥 和状态值,但是,在高流量站点存储和检索 会话状态很快成为瓶颈,并且在负载平衡站点中 您需要将用户会话绑定到特定服务器。

    重量级的解决方案是将会话数据存储在数据库中 所以它很容易从几个服务器上获得。

    对于复杂的更新,您还可以考虑从 CRUD 模式转移到更多 复杂的工作流模式。 在工作流模式中,您将用户输入更多地视为 必须通过多个过程(创建、验证、 批准等),然后再采取行动。

    您可以将输入存储为相当复杂的 xml,同时请求 更新和当前状态。可以存储多个表的更新 在单个 xml 中,并且仅在所有更改完成后的最后阶段 已输入、验证和确认的是基础表已更新。 您将屏幕与每个状态相关联,用户在屏幕上的操作 导致新状态,就像在经典的有限状态机中一样。

    这种方法的一大优点是“表单”与 用户而不是会话,因此,可以输入和编辑输入 几天内多次会议(这也可能被认为是一个缺点!)。

    【讨论】:

    • 实际上,我们尝试将与数据库的每次交互都减少为单条记录操作。例如,如果我必须管理包含多个详细信息的主发票,我会将发票以“草稿”状态或类似的状态保存到数据库中。我让用户编辑、暂停、恢复,做他喜欢做的任何事情,将记录逐条保存到数据库中。当发票“关闭”时,我会对其应用所有验证......这样我的数据库层就非常简单了,我的网页只需要保存一条记录......
    • 也就是说,我没有将用户数据保存在数据库上的 xml 中,而是将数据保存为“草稿”、“正在进行的工作”或类似的东西......跨度>
    • 拥有特定 WorkInProgress 存储的一个优点是您不必在应用程序中使用大量“AND STATUS NOT = 'draft'”谓词。
    猜你喜欢
    • 2017-03-19
    • 2018-08-07
    • 1970-01-01
    • 2014-05-20
    • 2011-04-24
    • 2016-02-13
    • 2020-07-27
    • 2018-10-22
    • 1970-01-01
    相关资源
    最近更新 更多