SunshineCRM主核心引擎实现过程

      开始的时候生成文件当中有三个文件，为什么有三个文件呢，因为说的是要基于MVC的思想来开发系统，所以任何一个表就用了三个文件，分别实现MVC这三个接口实现，事实上这种作法，对于开发人员只有我一个的人来说是一种麻烦，在以后的代码升级的过程中就显示出来了，在想在系统里面修改一个基于表的应用，就得分别到database和html目录里面分别找到相应的文件，然后再到控制层里面找到相应的文件，来修改，任何一个地方的修改都需要涉及到那三个文件，在视图层里面来修改界面元素，在逻辑层来实现对数据的操作，然后再到控制层里面，把相应的模块联接起来，对于人的耐性来说真是一种考验。不过那时不知怎的也过来了，到现在那些当时写的代码，还在那里面放着，由于代码先天的设计不足，就导致那些代码维护起来非常困难，原因不是因为代码太难读，而是因为代码修改的时候需要太多的人力成本。
      回到上面的话，上面提到，设计的初始化原于一个己经写的开发模版，一个表的应用，实施之后就会生成的可以运行的代码，其中模版的好坏直接决定了生成代码的质量问题，看到这里，你可能会发问，只要改进模版的质量，生成的代码不就先进了么，答案是这样的，生成的代码只能满足以后代码生成的需求，而以前生成的代码，对于现有的代码模版来说是有一定缺陷的，而生成的代码，在经过详细的需求变动之后就不能用现在新的模版生成的代码来覆盖了。这也是其中的一个问题，就这些问题一直在我的头脑里面存在着，而我没有太多解决问题的办法，这种情况一直持续了将近有一年的时间。
      （无意间的突破）

      读过几天学的，都应该知道政治学里面一句话，叫做从量变到质变。或许是我的不断努力，而使其感动，而我在不经意就找到了它的一个对策，这个对策的完善，就是现在的开发引擎的核心所在。
      由于问题的存在，而使我不得不寻求一种可以使用的对策做为补充，可实际上我没有找到，但是我想到了，想到是可以用一种类似于编译器生成编译代码的思想，来生成一些可以运行的中间代码，一旦核心引擎得到改进或是描述部分变动，其可以立即在生成的中间代码中得到体现，这里面中间指的是可以在系统的执行的语言代码，只不过这些代码是生成的，可以变动的罢了，其它都和原生语言一样。这种想法，很好，但却没有能功能地设计出当初的设计，原因可能有一个：对这个引擎究竟是怎么回事，不是很清楚，只知道不能犯以前的错误就可以了。事实上它的测试力度非常大。而且要根据里面生成的代码来实现错误的寻求，然后再反映到引擎上来，这样又增加了系统的复杂度，所以其理所当然地当了，不过这些应有的设计却没有当有，只不过它没有能生成代码，而是把配置文件读入之后，立即执行，没有编译成代码，再通过代码来执行，这样有一个好处是非常好的，就是错误结果可以非常容易地找到，并得到改正，所以这样系统慢慢地得到不断的改进，新的功能上的模块也被加入，所以引擎慢慢地完成。