ORM，我们应该可以试试ECO框架

我是编程菜鸟，但在业务上我不能算是完全的菜鸟，因为我本身就是企业业务人员（我是会计）

可能因为这样的背景，导致我特别喜欢ECO框架这样的东西

我看到园子里有个程序员写道，如果什么都要机器干了，那还要我们干什么

但从我的角度看，任何工作，只要运用自动化工具的结果是提高整体效率降低总体成本的，就应该考虑使用自动化工具，商业行为的评价标准是利润，而不是你做的事情的复杂程度有多高，理论上用1、0这两个数字写代码复杂程度最高，你愿意去做这种高难度的事情吗？

ECO就是我眼中一个非常好的自动化工具，它让我的编程工作一定程度上变得相当的傻瓜化

大体上用ECO框架工作的过程如下：

1、分析需求中需要管理的对象是什么

2、根据需要管理的对象确定实体类，定义其属性与行为，提取抽象类，确定类关系，在ECO中画好类关系图与状态图

3、使用对象信息集控件，用OCL语言表达式使得对象信息集控件从类关系图中获取对象的基础信息或派生信息

4、将界面控件与对象信息集控件相关联以获得程序的界面表达

5、较为复杂的业务逻辑用一些代码完成（查询方面的逻辑则几乎可以完全用对象信息集控件完成，事实上从我的程序员同事的工作来看，做为一种较为优秀的对象查询语言，OCL可以完成几乎全部类型的信息查询工作，而且比表查询语言SQL更符合人对客观事物的感知，因为SQL查询的是表数据，OCL查询的是对象信息）

6、运行程序，输入业务数据验证程序实现的业务逻辑是否符合需求（嗯，你现在可以把这个开发成果打包了）

7、如果你暂时还不需要保存数据，那么就不需要加持久化控件了，只不过程序关闭后输入的业务数据会丢失而已

8、如果你需要保存输入的业务数据，那么在运行之前加一个数据持久化控件，可以选择用XML文件保存数据，也可以选择各种流行的数据库产品来保存数据，只是选择一种数据库后，你需要再按个按钮让ECO框架自动生成数据库结构而已

9、你的工作结束了，现在运行程序就可以保存业务数据了

这样，我们会发现，业务逻辑层与数据库无关了，整个设计过程与数据库无关了，整个设计过程中不存在数据库表的概念，也不存在数据库的概念，只存在对象的概念，用ECO框架开发产品，数据库是最后选用的东西，它仅仅是用来存放数据的仓库而已

也就是当你做完第6步时，你就可以把程序打包了，这个包可以给你的项目组用，也可以给其它项目用（如果其它项目在需求分析过程中分析出类似的需求的话），其它项目组可以随意修改你的这个包，很灵活，很方便，你的包不仅完成了业务逻辑，而且与数据库无关，将来想挂什么数据库就挂什么数据库，比如你的包在这个项目组里用上，最终这个项目可能是挂ACCESS的，在另一个项目组里用上，最终那个项目可能是挂ORACLE的，一点都没影响

我认为ORM诞生的最重要一点，就是希望程序员脱离数据库的概念，纯粹的去完成业务逻辑，而ECO框架做的很好的一点就是，它提供了这样一个环境，允许程序员脱离数据库概念纯粹的去完成业务逻辑

我看过有一些讨论ORM的贴子后会觉得很奇怪，你们都ORM了，怎么还会去讨论“表”、讨论“数据库”、讨论“SQL语句”这些东西呢？？

有些人说ORM适合大项目，也有人说适合小项目，在我看来，有关社会事务管理应用的项目，无论大小都很适合

比如我现在在初学编程阶级，做的是低复杂度简单案例

比如我的同事是正经程序员，做的是大型高复杂度项目

大小项目都可以用ORM，看你怎么看问题而已，当然首要一点，如果想运用ORM，尤其是ECO这种高度傻瓜化的ORM框架，劝大家把数据库以及表的概念完全忘记先

 忘了说一句，用ECO框架开发，需要手工写的代码量好象是真的极少的