早在2012年，我遇到了属性拦截器的问题，这些问题是递归的（也就是说，它们会在同一个属性上触发拦截器但是会产生不同的实例）。似乎DevForce将忽略除第一个拦截器执行之外的所有行为，并且行为是预期的并且是设计的。有关详细信息，请参阅this forum post。我能够在我的应用程序中重新设计一些东西以解决这个问题，并且一切都很好。
现在我遇到了同样的问题，无论如何我无法想出来解决它。我的新方案正在破坏我们的应用程序中的一个功能，其中对一个字段的更改可以触发对其他字段的更改，并且此行为全部是动态的并由运行时配置控制。在某些情况下，我们希望在一个实例上更改属性以在其他实例上更改相同的属性（这可能是我们实际用例的简化，但希望它足够接近）。在调试了那个逻辑中的一些错误之后，我意识到由于同样的递归限制而无效。
我尝试深入研究DevForce代码，看看是否有我们可以解决这个问题，但我没有成功。有什么办法可以让它发挥作用吗？我可以理解论坛帖子中提到的关于如何导致无限循环的问题，但在我们的案例中，我对这种事情很好。如果我编写会导致无限循环的代码，我宁愿接受一个易于调试的挂起的应用程序，而不是一个即使事情被巧妙地破坏也会默默地继续工作的应用程序。
这让我想起了我们遇到的this other issue。我可以理解DevForce可能想要尝试友好并且默认尝试掩盖编程错误，但我也想控制这种决定。从另一个问题，添加了一个选项，所以我可以告诉DevForce有新的行为（EntityManagerOptions.ThrowAllLoadExceptions）。也许可以为此添加一个类似的选项？我希望在某个地方AllowReentrantPropertyInterceptors选择我可以转到true（默认情况下为false以避免向后兼容性。）
如果全局选项看起来太危险，我可以使用PropertyInterceptor上的公共财产，例如ReentrancySupported或其他东西。我可能最终只需循环遍历模型中的每个属性并将其设置为true，但这样一个全局选项会更好。