在这个简短的系列中，我想介绍一些简单和不那么简单的方法， Mendix 应用程序可以变得更加高效。理想的结果应该是应用程序在尽可能短的时间内完成其工作并消耗尽可能少的资源。

总是？

序号

有时， 权衡 之间 一个选项 可读且可维护 或者可能是一个更高度优化的版本 巧妙和 更多 高效 但很难理解 这对您或其他开发人员来说将来维护代码会是一个问题。

这是团队在开发过程中或调查性能问题时做出的判断，高质量的注释或文档可能有助于促进对不清楚的代码的理解。

也， 某件事物运行得越频繁，可能性越大 得益 ，来自 提高其效率. 如果某个操作可以优化为只需 5 分钟而不是 10 分钟，但每个月只运行一次，那么在寻求提高效率时，该操作可能就不再是关注的重点，而对于每天运行数千次的操作，提高半秒的效率则无疑具有更高的优先级。

金色老歌

一些设计模式 Mendix 之前已经重点介绍过，但值得再次关注，因为有时新手和经验丰富的开发人员都会忽略它们。

循环循环

使用循环创建或修改微流中的对象时 收集 同一类型的新对象/修改对象 名单 和 承诺 那个清单 学校以外 这个 循环.

代替：

您可以使用：

这意味着 一次提交 用于 Order 对象，另一个用于 OrderUpdateAudit 对象，在流程结束时用于新的和更改的对象。 提交可能很昂贵 因为每个提交都要求您的应用程序运行一次往返数据库的行程，并且每次往返都会带来开销，所以将提交批量处理可以减少往返次数，从而减少开销。

让你的骨料飞起来！

此 Mendix 由于代码编写较少，运行时会花费过多的时间来优化数据库查询，例如在微流中，你可以放置一个 紧接着检索活动列出聚合活动:

这导致 运行 至 执行一条语句 针对数据库，它将计算 Order 的 OrderValue 的平均值。Order 记录将完全不会被检索到应用程序中，并且实际上不会生成 OrderList。这将使执行速度更快。

但是，随后重新使用生成的列表可能会破坏这种优化。

现在，在运行聚合之后，OrderList 再次被使用（作为 IteratorOrder 循环的数据源），这意味着 Mendix 恢复到标准行为并执行检索以将所有记录加载到 OrderList 中，然后通过向下扫描该列表中的记录来计算平均值。

在这种情况下，很可能 快 运行 取回 活动 两次 — 一次 要使用的聚合 并再次 获取记录列表。这在本例中尤其适用，因为第二个 Retrieve（现在是 IteratorOrder 循环的源）仅在计算出的平均值足够时运行，因此如果平均值较低，则根本不会检索列表。

使用 Nanoflows 代替 Microflows

微流 是执行在 Mendix 服务器，经常由用户的 Mendix 客户。 纳流 可以执行许多与 Microflow 相同的活动，尽管在某些情况下，它们的工作方式与 Microflow 的工作方式不同。最大的区别是 Nanoflow 在 Mendix 客户 （用户的浏览器或本机应用程序）这可以使 Nanoflow 比执行类似功能的 Microflow 具有很大的效率优势。

此微流通过用户界面上的按钮调用，并实现可能更新所显示对象的业务规则。单击按钮会导致从 Mendix 客户端返回服务器上的应用程序，要求运行微流并将结果返回给客户端。

这个 Nanoflow 做同样的事情。从功能上讲，它几乎与 Microflow 相同，但整个操作在用户的 Mendix 客户端，这样客户端对服务器的调用、服务器上代码的执行以及结果返回给客户端的过程就不会发生。这减少了网络流量，避免了服务器中断来为用户执行更改。

使用 Nanoflow 并不总是一个好主意。如果您的 Nanoflow 需要调用 Microflow 作为其功能的一部分，那么您可能无法节省任何东西，因为仍然会发生网络交互和服务器中断。如果您的 Nanoflow 需要调用多个 microflow 或需要从数据库中检索更多数据来执行其功能，那么使用 Nanoflow 而不是 Microflow 可能会适得其反。