1.高性能是Moon.ORM优势之一,也是我架构它的主要目的之一,我已经将它的性能提升到了极致.如以前我说的那样,是为了弥补项目中遇到的性能问题而设计.可以说对于整个框架数据处理上采用了纯的ADO.NET进行自动编译的同时结合了EMIT达到快速生成实体的目的.
我不得不承认linq和lambda语句带来的优雅,但同时我们需要承认linq的局限性.或许有人说可以通过手段进行一些弥补,如有人以提高 linq性能来写文章一样,但我们需要承认两个事实,每次对linq的系统识别后才能进行优化,也就是说,linq的天性决定有性能损失.再次linq不 是银弹,因为负责的场合linq几乎是做不到的,何况linq生成的sql不一定是你真正要的.(注意:我不是敌对linq,而是说实话,正如曾说:实际开发中没有银弹,只有平衡点,适合需求能解决实际情况的架构那就够了)而且我也没有必要再去写一个框架,做一个类似Nhibernate,或者实体框架的东西.做东西我一直认为需要做一个能有自我的特色和优势.
2.易用性强大,我想用过Moon.ORM的应该可以知道这点.配置简单,智能感知,代码生成器的辅助,会sql就可会用Moon.
3.多数据库多数据源支持.在同一个项目中我们需要处理这种情况时,Moon.ORM是你最好的选择.如你系统默认为MSSQL,现在要同时使用 MYSQL,你只需要实例化一个引擎就可以.DBFactory.GetEntity<Person> (pjy_AdminRoleTable.RoleID.BiggerThan(0),new MYSQL("连接字符串"));当然你可以把引擎做成全局的.
4.语法糖功能.个人使用的结果是大概能满足我实际需求的70%以上的功能.
5..NET 2.0原生支持,这个就不用说了.
6.数据库转变问题,如果你发现你有一天你的数据库需要从mysql转变到mssql,你只需要转变你的配置文件即可.(当然sql语法差异的问题,你需要自己注意了,如果你在用原生的sql进行操作时).
历经了两个公司的发展,稳定性可得而知.曾在合富网络的主营产品中应用于一年的开发框架中.及潘家园文化传媒主营平台新系统.且得到Moon爱好者在实际项目中的肯定.
3.使用问题
此框架对于任何人群及个人可以免费使用.
有人曾说'都没源代码,所以我不能用'.我不能自比微软,但我们可以换一个位置想想:知道.net framework 3.5 sp1中的bug吗?微软的库中也会有bug信吗?Moon.ORM标准版,一律免费使用(包括API文档等)和群技术支持.对于企业用户我会提供专门的服务和技术支持以及更加美观强大易用的企业版Moon.orm代码生成器工具及技术培训资料.
4.常见问题
1.代码生成器在sqlserver2000暂未提供技术支持.
2.没有主键的表代码生成器会报错
3.系统中非.NET有的字段类型不支持
5.同类产品对比
1.对于实体框架,实体框架的性能问题,我不知道现今如何,但4.0的测试中足以见到http://www.cnblogs.com/humble/archive/2011/05/19/2051053.html
这也是我前一公司项目延期的一个原因.当时Moon.ORM还是1.0的版本以Qin.Data命名.
我不是要说实体框架怎样,至少那时的它让我们陷入沼泽,性能有时候是项目的关键.
2.对于Nhibernate,它的确不错,但不可置疑显得很复杂,或许简单易用可以作为Moon与它的对比吧.
3.对于iBATIS用过的人就知道,一堆的配置,每当要做查询你需要从写一堆配置.
4.其他类型的我就不想多说了,因为实际项目中没有银弹,适合环境适合自己的那才是最好的.您若不满意请飘过.
5.我不得不说没有一个ORM可以解决正真复杂的sql问题,nhibernate和ef同样也是如此,这也是Moon所面临的.
6.使用说明
7.最新版下载地址.
1.对于数据库的设计,每一个表必须要有主键;
2.由业务决定逻辑的主键设计方案是错误的,所以主键是不能被业务牵制的,因为业务是变动的.Moon.ORM需建立独立于业务
之外的.所以主键的设计MOON选择的是guid或者自增的情况(建议用自增的方式).
9.配置问题
1.下载代码生成器(上面,最新版本下载)
2.修改代码生成器的配置文件.如下图.(如果是mysql见 6.使用说明)
3.运行代码生成器生成实体
(可以把这段代码文件.cs复制到项目中,也可引用编译文件.dll)
4.实际项目中引入Moon.Orm和上面生成的.cs或.dll
