探讨后遗症。做工程框架中，做了几百个触发器。整个游

PassByYou

我没时间写详细文档。文档上只能写写大思路。

预料中的后遗症：
开发者：这个触发器怎么写？那个触发器怎么写？怎么能回答的过来啊？

假如发生深层逻辑问题？

怎么清除大量冗余代码？

触发器多了，某些底层的，诸如刷贞，BeforeRender，AfterRender被挂太多接口，还有就是AI部分，反复运算量很大。那些正确的使用思路是个大问题。

conquerors

个人观点,有错误请指正
    为什么要触发器呢?或许是因为AI本身 不够 intelligent
        或许可以通过设计更合理的AI算法来达到(或者改良)触发器的效率

clayman

...................

zotin

使用触发器比较容易实现，如果完全依靠AI来处理所有的情况，AI的设计要求太高。
还要考虑到其他非底层程序员的理解能力，所以完全不用触发器还有些困难。
如果不能够做大的改革，做一个强大的触发器管理工具也许能在一定程度上解决触发器混乱的问题。

PassByYou

大部分人看过此贴并没有发言。
从这点感觉这些人都比较不喜欢探讨问题。可能比较喜欢独断。

我做了一个主框架，这是在我看来比较完善的。
然后在做它的时候，我发现很多隐藏的问题。诸如我提出了触发器多了真不好管。而你给了我一个解决上的思路。

在你的思路上，纠正一下。
不应该称呼它叫触发器管理工具，因为触发器都是源代码，源码怎么管？按文件来管？干脆叫触发器使用向导，或则叫触发器速查。

因为大多系统中的触发器，都是基于数模在做事件+数据交换。这样基于有层次的触发器使用，要了解一些整体构架才行。所以我又提出了怎样使用，怎样传播思想。

主框架蓝图没有问题，最近实现抓得比较紧。

讨论大有益处。