ORM框架-EntitysCodeGenerate一些使用项的介绍

ORM框架-VB/C#.Net实体代码生成工具(EntitysCodeGenerate)【ECG】目前已是4.3版本了，支持.Net1.1及以上版本。在4.3版本中，工具引入了对PowerDesigner文件的支持，目前为止可用于Oracle、SqlServer、MySQL、Access、Sybase、SQLite、DB2、PostgreSQL、DM(达梦)、PowerDesigner文件、Informix、Firebird、MaxDB、Excel等和OleDb、ODBC连接的数据库，同时也可以自定义。

这里介绍下一些使用项方面的东西，比较简单，看下即明白。

 

1、数据库设计的规范化建议

使用工具在设计表时建议：数据库表名及字段名应当遵循通用规范，如都使用大写英文字母，首字符以大写英文字母开头且不含有特殊符号，如'┋'字符；表中不含有嵌套表、表名不与字段名重复等。另外文字命名可约定俗成为单数形式，可以是英文字母及数字和下划线(_)组合，此外可以约定表命名以"T_"开头，表字段以"C_"开头，视图以"V_"开头等，这样做的目的可使数据库设计更规范化，也避免了与关键字的冲突带来一些不必要的麻烦，同时也是因为许多数据库都是英文字母开头的且不能含有特殊字符，如Oracle就是这样，且表名称和字段名都是大写(对PostgreSQL建议采用小写命名)，长度不超过30个字符(命名过长无意义,有些数据库也不支持)，多出的信息可以在命名注释里多写些注释信息。若采用Oledb、Odbc方式连接，表字段名最好不要这样FIELD1,2,3...以数字顺序结尾，因为这样容易与参数机制冲突，导致一些数据访问时带来一些参数上不必要的麻烦，且这样命名也不是好的规范，必要时可以是FIELDA,B,C...。每个表建议都设置主键，可以是联合主键。若没有主键，则在使用主键判断记录的唯一性时应指定判断字段。

 

2、数据类型映射文件的配置

EntitysCodeGenerate默认提供了各种类型数据库的绝大多数字段类型的映射，但仍然不能做到全面完全的映射，一方面作者时间精力所限，另一方面各数据库厂商也在对其DB持续升级，所以提供了数据类型映射文件(DbTypeToCSharpType.xml)。对于没有配置的数据类型，ECG工具默认以string类型代替，同时记录到日志“相关配置->没有配置的数据类型映射信息.txt”文件里。如果有没有配置的数据类型或自定义的数据类型，可以在配置文件相应配置节追加。但不建议填写带"?"数据类型。

纠正：在4.2及之前的版本，对于Oracle数据库的LONG类型应是字符类型(string)。

 

3、数据类型的初始值设置

对.NET提供的数据类型，提供了数据类型的初始值文件(DataTypeDefaultValue.xml)，ECG工具对基本的数据量都设置了默认值，如果有其它数据类型或不想设置默认值，可以修改该文件。

 

4、配置信息存档

很多时候，业务需求总是再不断的变化，数据库结构需要变动(表结构修改或增加减少表等)，这时就需要重新生成实体。虽然ECG工具提供了快速生成实体的方便，但如果每次都要重新输入相同的配置信息，也存在诸多不便，工具的帮助菜单下“帮助->配置信息存档->存档、导入存档”，可以将某次的成功的配置信息保存下来，供下次导入使用。

还有，有些情况，你的表可能会很多，甚至成千上万张，而每次调整也许只是局部调整。这时你可以使用“选择生成”，并且你还可以将选择结构“导出选择、导入选择”，供后续使用。

 

5、缓存(Cache)与性能

一个不可回避的话题，ORM在节省大量重复模式Code的同时，也或多或少带来了性能上损失，然而通过Cache的实现能够对性能调优。

让我们来分析一下性能瓶颈问题，当今的计算机已不再是386/586的那个时代了，CPU的运算速度不用担心的，主要是I/O交互时间。不管你是否采用ORM，在一次完整运行任务中如果需要不停的I/O交互，则不论你怎样Code，性能还是不咋的。所以ORM并不是性能慢的根本原因。在Asp.Net中，System.Web.Caching命名空间提供的Cache就是一个很好的选择，CacheDependency用于缓存依赖。这样在应用程序中如果需要I/O交互也只要首次使用进行I/O操作，以后只要直接重缓存中提取即可，如数据库连接字符串的配置文件等。详细的缓存策略可参见微软MSDN.

还一个就是大数据量问题，当一次查询出很多数据时，无论是不是用ORM，查询都不会快的，因为这时I/O耗时将会很长。对于大数据量表的查询，首先就是使用索引性能优化，还有一个就是分页技术，按需查询，目前为止本人还没有见过哪个用户屏幕一屏显示一千行以上数据的，一屏一百行的也没见过。当然特定的数据库技术处理上还有许多方式，则是DBA的特长。如果数据处理复杂，可以用DbCore+SQL/存储过程，实际中这部分在项目中所占比例不会太多，当然有些时候这部分也可以在项目后期来做。

 

6、三层与多层架构

工具提供示例中的ECG.Demo是常见的三层架构模式，对于多层架构同样适用，SimpleFactory目录下简单显示了多层架构模式中的示例。从这里也可以看到该ORM工具适用各种数据库，可以灵活切换；即使是复杂处理那部分解决起来也同样方便。

另外，这里，实体(Entity)可以方便的与XML相互转化，对于现在企业多系统应用集成也有很大的好处，因为各种原因企业各系统使用不同的数据库，而随着企业的发展，需要用到各系统中的数据，所以就需要在系统之间信息的集成，甚至一些大型企业地域分布较远，考虑安全问题各系统之间很可能不能直接交互，需要用到XML文件内容传输，而这时该工具无疑提供了良好的解决方案。

 

本篇就写到这里，后续再见！！！