分享高效的实体类操作类,分析其优势,可自己写替代EF的ORM框架

qldsrx 2012-04-12 10:43:05
加精
这次发博发这里了,免积分下载,支持获取动态实体类并让控件加载。
http://blog.csdn.net/qldsrx/article/details/7452346

下面是代码分析:

public class Dog
{
public int? Age { get; set; }
public Guid Id { get; set; }
public string Name { get; set; }
public float? Weight { get; set; }

public int IgnoredProperty { get { return 1; } }
}

var guid = Guid.NewGuid();
var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

这个查询,返回的是Dog类的集合,参数是一个匿名类,2个属性(Age和Id),其实除了匿名属性作为参数,实体类本身也可以作为参数,这意味着你可以很方便得从一个实体作为条件,获取其相关联的其它实体,写代码会很方便,无需自己写参数构造过程了。

在看这段代码:

connection.Execute(@"insert MyTable(colA, colB) values (@a, @b)",
new[] { new { a=1, b=1 }, new { a=2, b=2 }, new { a=3, b=3 } }
).IsEqualTo(3); // 3 rows inserted: "1,1", "2,2" and "3,3"

这是非常有意义的写法,当我们批量更新一个List<T>内的实体的修改是,直接把这个List作为参数传递给它即可,Sql语句自己定义。而以前的写法都是循环集合中的每个实体,然后创建参数,对数据库提交修改。

最后看这段代码:

class User
{
public int Id { get; set; }
public string Name { get; set; }
}
class Post
{
public int Id { get; set; }
public User Owner { get; set; }
public string Content { get; set; }
public Comment Comment { get; set; }
}
public void TestMultiMap()
{
var createSql = @"
create table #Users (Id int, Name varchar(20))
create table #Posts (Id int, OwnerId int, Content varchar(20))

insert #Users values(99, 'Sam')
insert #Users values(2, 'I am')

insert #Posts values(1, 99, 'Sams Post1')
insert #Posts values(2, 99, 'Sams Post2')
insert #Posts values(3, null, 'no ones post')
";
connection.Execute(createSql);

var sql =
@"select * from #Posts p
left join #Users u on u.Id = p.OwnerId
Order by p.Id";

var data = connection.Query<Post, User, Post>(sql, (post, user) => { post.Owner = user; return post; }).ToList();
var p = data.First();

p.Content.IsEqualTo("Sams Post1");
p.Id.IsEqualTo(1);
p.Owner.Name.IsEqualTo("Sam");
p.Owner.Id.IsEqualTo(99);

data[2].Owner.IsNull();

connection.Execute("drop table #Users drop table #Posts");
}

这是多实体联合查询的示例,通过传递一个关系函数,得到一个根实体,访问根实体Post的属性User,可以得到相关联的User,这在多表联合查询中修改中非常有意义,而这个根实体其实可以用动态实体来替代,这样就非常完美了。

有了上面这些强大的基础功能,我们只要封装下从数据库中映射的实体类的基本SELECT、INSERT、UPDATE、DELETE语句,那么连SQL语句部分都可以不用写了,一个非常强大的ORM框架就此诞生,还支持动态类型查询。

这个强大的实体类只能在直接访问数据库的情况下使用,如果要在远程方法中调用(如WCF),则必须做大的改动,而Silverlight对匿名实体类的处理又有所不同,因为不支持TypeDescriptor类,将无法动态构造属性说明,因此必须动态创建一个新的类型来处理,这个处理难度非常大,目前正在设计阶段,主要技术问题都已解决,正在ORM框架的构建中。

本人业余编程,自认为水平已经很专业了(仅限C#),如果有C++高手可以指点下C++下面的实体类处理,我好让设计的动态实体类可以更多的跨语言,跨平台。
...全文
10745 363 打赏 收藏 转发到动态 举报
写回复
用AI写文章
363 条回复
切换为时间正序
请发表友善的回复…
发表回复
ydtpan 2012-04-28
  • 打赏
  • 举报
回复
与期争论不休,没有结果。 不如楼主给大家讲讲这个类的优点在哪儿。
让大家有收获,比争论是直接面向数据库编程或是面向对象编程哪种方式好,来得有价值。
谈谈这个类你觉得好的,抽几个出来详细说明。
owen_chen007 2012-04-27
  • 打赏
  • 举报
回复
活到老学到老
窗户纸 2012-04-25
  • 打赏
  • 举报
回复
当然我觉得你的模式也有缺陷,就是“类SQL" 语句仍然需要学习才能掌握,新上手的人对SQL都有恐惧感,就甭提你的“类SQL”了。
窗户纸 2012-04-25
  • 打赏
  • 举报
回复
从我上面举的几个小例子看,业内已有的“框架”类通用软件(如LING to Sql, Hibernate)之类的在实现特殊功能和特殊效率提升存在局限性,而自己定制的系统可以很容易的实现我所需要的后期灵活优化。

在发散一下,这里面有些提到实体与数据表关系时表述的很混乱,比如一个实体管理多少表之类的,实际上对象体系与数据表体系是有联系的,做过一两个系统,真正按照面向对象的设计思路做做 很容易就会发现。

不过很多人抱怨的面向对象编程问题,一个很重要的因素可以说是他抽象分析能力有待提高(比如用友号称有上千个表,但他每年结算就用一套新表,那数据表不多才怪,难道不能设计一个年份表去关联相关表解决吗?SAP不是这个设计,所以他没有上万张表,不然SAP架构设计师自己就自裁了,而用友则脸皮比较厚)
窗户纸 2012-04-25
  • 打赏
  • 举报
回复
[Quote=引用 358 楼 的回复:]
只有ycg_893、sp1234理解了我分享的操作类,其他人不是没发表见解,就是直接跑题谈论其它的去了。那么好的一个工具类不好好研究,而去纠结什么设计模式,真是本末倒置了。本想那么难的代码,看不懂你们可以多提问,我来解答细节,可惜却偏偏争论其它的去了。
[/Quote]
青龙老弟不要气馁,我粗看了一下代码,貌似你试图解决的是如何提高传统映射方式的处理效率问题。
比如对于传统的ORM模式如果查询年龄>2岁的黄色狗需要取所有狗逐一遍历结果,再提出合适对象返回集合,而你的方式直接使用特定的“类SQL"语句即可实现快速查询,其效率显然比单纯的ORM快很多,更新等也是类似。

我的项目所采用的方法是先不考虑效率,业务层及界面层编程人员仅对对象操作,在后期功能定型后再进行一个优化阶段,针对影响效率的数据提取方式设计并实现单独的接口及sql实现。

你的模式优点在一开始就可以保证系统的运行效率,但如果希望数据表变化后业务层不受影响,就需要对"类SQL语句"进行翻译。如数据库表的AGE 改成godAge, 业务层仍可使用Age属性。不知是否有实现。

另一种需求,比如用户在线标记属性,ORM写入会整个对象操作,而在线与否由数据库控制,必须单独写入及读取,这就必须建立一个特定的接口进行操作,否则就会造成错误(客户端改了用户信息,结果用户下线变成上线了)。
另外有人提到表间级联查询时的效率问题,这个问题也很重要,我们的处理方法是后期设置专门的接口,定制sql实现,
比如:查询存在年龄〉2岁的黄色的狗的狗舍集合,我们在狗舍对象中增加内部静态finddogzone(int age, short color)方法,
实现时select dogzone.* from dogZone inner join Dog on dog.dogzoneID=dogzong.id where
dog.age='{0}' and dog.color='{1}' ...
然后在顶级系统对象中增加开放的finddogzone(age,color)方法。
qldsrx 2012-04-25
  • 打赏
  • 举报
回复
只有ycg_893、sp1234理解了我分享的操作类,其他人不是没发表见解,就是直接跑题谈论其它的去了。那么好的一个工具类不好好研究,而去纠结什么设计模式,真是本末倒置了。本想那么难的代码,看不懂你们可以多提问,我来解答细节,可惜却偏偏争论其它的去了。
showjim 2012-04-23
  • 打赏
  • 举报
回复
[Quote=引用 333 楼 的回复:]
2.ORM的根本缺陷就是认为业务和数据的映射关系,你们所说的所谓"实体"无异于把数据库硬拷贝一遍,
无论是DBFirst还是CodeFirst,根本思想还是"数据驱动",用一种实现驱动另一种实现
并且,除非你们能从代码中自动"反射"出完整的设计文档,
否则,项目很难快速重建
[/Quote]
ORM映射与业务没有必然的直接关系,你说的缺陷不成立。
数据库硬拷贝确实能带来一些优势,并不是茫无目的。
CodeFirst不仅仅是数据访问,所以它并不是你眼中的"数据驱动"。CodeFirst是基于程序定义驱动的自动化,也许是数据结构,也许是函数定义,也许是一个模版,也许...我个人的实现多数针对.net元数据。
程序就是设计文档,要"反射"出所谓的“文档”是很简单的事。
因为IDE支持重构,项目的重建也很简单。
[Quote=引用 337 楼 的回复:]
你所赞成的那种基于ORM思想的所谓"实体"无法实现你所倡导的价值取向,
超过80%的这样的代码背后的业务逻辑都是在一遍遍重复实现,
(当然,我假设业务领域是基于数据库的企业信息管理系统)

设计师的工作不是编程也不是sql,他们的工作成果是设计文档,
项目的关键价值在设计文档,而不是那些代码,
一切软件生产工序都是有设计文档驱动的,
文档完整,就可以保证向后兼容和快速重建
[/Quote]
业务逻辑是否重复实现与ORM毫无关系。
我不明白,Code First不能向后兼容?不能快速重建?
[Quote=引用 338 楼 的回复:]
比如说,你实现一个订单业务,不应该依赖具体的数据结构,
哪怕设计的就是采购订单业务这样具体的业务,
那也不应该可数据库中的PurchaseOrder有任何依赖关系
这个业务实现应该支持的是:
任何实现了相同设计接口的数据结构和数据处理
[/Quote]
既然业务实现应该支持接口,这和ORM冲突吗?
ORM映射的仅仅是原始数据结构,可以仅相当于一个面向程序的扩展数据库操作接口。
zhongchengli 2012-04-21
  • 打赏
  • 举报
回复
[Quote=引用 328 楼 的回复:]

如果能封装SQL语句就更好了!
这样才能对应多种数据库!

参考--------------------------------
http://www.cnblogs.com/szp1118/archive/2011/03/30/ORM.html
设计思路:

1.数据库中的一张表需要和实体类进行对应,表中的字段对应到实体类的属性,不一定都要一一对应,可以有属性不对应到表中,但是……
[/Quote]
还有就是我们的项目为了保护客户数据,数据库字段都是A,B,C...
zhongchengli 2012-04-21
  • 打赏
  • 举报
回复
如果能封装SQL语句就更好了!
这样才能对应多种数据库!

参考--------------------------------
http://www.cnblogs.com/szp1118/archive/2011/03/30/ORM.html
设计思路:

1.数据库中的一张表需要和实体类进行对应,表中的字段对应到实体类的属性,不一定都要一一对应,可以有属性不对应到表中,但是一般情况下数据库字段都应该对应到某个属性,否则就没法对该字段进行操作了。有时候在列表页和详细页需要获取的数据不同(列表页是少数几个字段),这种情况下可以定义一个少量字段的实体类,再定义一个所有字段的实体类(继承至前一个类)。

2.由于.net的基本类型例如int,bool等都是值类型,意味着无法赋值为null,它们都有默认初始值,int为0,bool为false,这样的话自动处理就无法分辨出是默认赋值还是用户自己赋值,所以实体类中的属性就必须是引用类型,对于.net基本类型就要做可空处理了(.net 2.0新增功能),如 int? , bool? 这样来定义实体类的属性类型。
--------------------------------------------

哪位高手给个好点的设计思路?

  • 打赏
  • 举报
回复
点开楼主一开头的连接,看到原文,那么就可以看到lz他自己写的“为什么要开发此框架”的基本解释。理解楼主为什么要“自己开发框架”?理解楼主为什么首先要参考别人的框架?理解楼主为什么以使用中的“性能”为这个框架设计指标?

例如我们编程当然要追求最少量地设计对象类,但是不是说我们因此就绩效面向对象设计,不会面向对象设计的人跟滥用对象、继承概念的人其实是一样的。

因此去开发一个框架是有其原因的、有其目的,不是要求别人一定去模仿。不会按照自己的需要开发框架,跟做出几个无用反而降低生产率的框架,结果都是是一样的。
  • 打赏
  • 举报
回复
[Quote=引用 348 楼 的回复:]
那你发几个上来瞧瞧,
[/Quote]

晕!

我想你先尽量看懂楼主的帖子吧。
  • 打赏
  • 举报
回复
有一些框架总是正确的,关键是什么样的框架。

如果什么框架都没有,那么就是无头苍蝇式的开发,表面好像挺敏捷、而实际上只是一遍遍重复低层次的OA表单复制的“开发”工作。楼主的帖子,并不是在这个层面上才想到的,楼主也提示了,他是因为大量外部原因的影响、价值自己的水平足以开发一些工具类的项目(而不是只会编写OA表单),这才想到了要对传统的数据库表编程方法做出改变。
vsfdsfsd 2012-04-21
  • 打赏
  • 举报
回复
看是不是真的象你说的那么伟大,
vsfdsfsd 2012-04-21
  • 打赏
  • 举报
回复
[Quote=引用 346 楼 的回复:]
只有有人一个劲问“如何做?” --> 至于有人一个劲问“如何做?”


实际上所谓的“说概念条条是道,碰到实际问题束守无策”,这是对已经流行了超过15年的ORM毫无概念的表现。在ORM上流行的理论和书籍也很多,而且总是跟著名OOAD专著(而不是网路上的杂文)放在一起,作为“如何使用OOPL来实现ORM框架系统”的篇章。

我在各种项目中写过的ORM有好几个,还真的无法跟所谓“束手无策”这……
[/Quote]

那你发几个上来瞧瞧,
vsfdsfsd 2012-04-21
  • 打赏
  • 举报
回复
以用户需求为中心,然后什么对象,sql,
什么好用就用什么,对象sql,各有擅长,不要因为对象就去否定sql,
又不是搞传销,
  • 打赏
  • 举报
回复
只有有人一个劲问“如何做?” --> 至于有人一个劲问“如何做?”


实际上所谓的“说概念条条是道,碰到实际问题束守无策”,这是对已经流行了超过15年的ORM毫无概念的表现。在ORM上流行的理论和书籍也很多,而且总是跟著名OOAD专著(而不是网路上的杂文)放在一起,作为“如何使用OOPL来实现ORM框架系统”的篇章。

我在各种项目中写过的ORM有好几个,还真的无法跟所谓“束手无策”这样的描述扯上关系。
vsfdsfsd 2012-04-21
  • 打赏
  • 举报
回复
无招胜有招,
一切以用户需求为中心,而不是以什么对象啊,模式啊为中心,
以这些为中心,无疑是拿个套子把自己套住,
vsfdsfsd 2012-04-21
  • 打赏
  • 举报
回复
我们以前的会计老师,
说市面上的会计软件,没一个好用的,
都是程序员按自己的模式开发出软件,
然后要那些专业会计师,去适应程序员的模式,
用多了人都变傻了,

是鞋去适应脚,不是脚去适应鞋。
  • 打赏
  • 举报
回复
[Quote=引用 333 楼 的回复:]

引用 330 楼 的回复:
你宁可单独去“维护1000个数据库表”,然后再写1000中莫名其妙的DataTable组合(无模式)么?

写程序时,需要什么实体,就直接写什么业务,而数据库表自动化地维护(根本不需要更多人工操作),
1.设计文档自动更新数据库(DBMS不也是这样做的么?),并且只有涉及到新的没有实现过的业务逻辑的时候,才会需要人工编写代码;
2.ORM的根本缺陷就是认为……
[/Quote]

我所面对是,不是有没有数据结构的问题,而是像某些培训机构最喜欢的培训方式那样、只会拿着sql语句当设计的程序设计师,这时的问题就很严重了。

目前我只愿意围绕楼主的帖子,描述一下它可以做什么、如何做到的问题。只有有人一个劲问“如何做?”,请去问楼主。我对楼主的回复是有效的,楼主知道如何轻快地使用Attribute、DDL语句等来解决问题,这就足够了。别人有问题请去问楼主。
wanghui0380 2012-04-21
  • 打赏
  • 举报
回复
所以我们前面才会和你提IQueryable<T>,也就是不管以后怎么去提供那个privode,起码目前我并不关心,我们目前关心的是系统对象结构,边界提供,系统服务。
对于查询我个人是这么说,他总归是有手段解决的,他目前暂时不在我考虑范围内


也许后续提供有性能问题,他不重要,性能问题我们可以优化。第一步是把棋下赢,至于这棋是不是最好滴,我们说赢棋第一,先赢了才有话语权。

ps:有关上面那位纠缠Mvvm的和具体细节的兄弟,我先说一句不是我们和你说抽象,而是我们不能和你说具象的东西,一是微软本身依赖抽象,他依赖一些InontifyPropeytychanged,IErrrorInfo这些抽象,如果是我如果有人怎么说,我不会具体在问,我会先搞清楚这些接口都是啥,如何在具体项目里应用,只要你弄清楚他们,剩下的事情我们不用解释你就知道,同时对于lz也是一样,lz应该先去看一下IQueryable<T>,然后我们不用解释lz也就知道,他现在的东西微软不是没有,抛开linq2sql,抛开EF,如果我说我自己,可以如此

xxxx.join(yyyyy,y=>y.id,x=>x.id,(x,y)=>new (x=x,y=y)).where(p=>x.xx==1&y.yy==2)
我能提供正确的sql解析,并能正确查询出结果,那么lz就该理解我们的意思了
加载更多回复(308)
ef-orm A Simple OR-Mapping framework on multiple databases. 使用手册(中文)http://geequery.github.io/ef-orm/manual/EF-ORM-user-guide.docx  使用示例工程 https://github.com/GeeQuery/ef-orm/tree/master/orm-tutorial EF-ORM是一个轻量,便捷的Java ORM框架。并且具备若干企业级的应用特性,如分库分表、JTA事务等。 代码生成插件for eclipse(请在eclipse中Help/Install new software后输入地址并安装)http://geequery.github.io/plugins/1.3.x/特点一 EF的设计的一个主要目的是提高开发效率,减少编码工作,让开发者“零配置”“少编码”的操作数据库大部分功能。 例如:数据库查询条件的传入问题是所有ORM框架都不能回避的一个问题,所以我经常在想——既然我们可以用向DAO传入一个Entity来实现插入操作,为什么就不能用同样的方法来描述一个不以主键为条件的update/select/delete操作?为什么DAO的接口参数老是变来变去?为什么很多应用中,自行设计开发来描述各种业务查询条件才能传入DAO?为什么我们不能在数据访问层上花费更少的时间和精力?   JPA1.0和早期的H框架,其思想是将关系型数据库抽象为对象池,这极大的限制了本来非常灵活的SQL语句的发挥空间。而本质上,当我们调用某H框架的session.get、session.load、session.delete时,我们是想传递一个以对象形式表达的数据库操作请求。只不过某H框架要求(并且限制)我们将其视作纯粹的“单个”对象而已。JPA 2.0为了弥补JPA1.0的不足,才将这种Query的思想引入为框架中的另一套查询体系——Criteria API。事实上针对单个对象的get/load/persist/save/update/merge/saveOrUpdate API和Criteria API本来就为一体,只不过是历史的原因被人为割裂成为两套数据库操作API罢了。   因此,对于关系型数据库而言——Entity和Query是一体两面的事物,所谓Query,可以包含各种复杂的查询条件,甚至可以作为一个完整的SQL操作请求的描述。为此,EF彻底将Entity和Query绑在了一起。这种思想,使得—— 开发人员需要编更少。开发人员无需编其他来描述复杂的SQL查询条件。也无需编代码将这些查询条件转换为SQL/HQL/JPQL。DAO层也不会有老要改来改去的接口和API,几乎可以做到零编码。 对单个对象进行CRUD的操作API现在和Criteria API合并在一起。Session对象可以直接提供原本要Criteria API才能提供实现的功能。API大大简化。 IQueryableEntity允许你将一个实体直接变化为一个查询(Query),在很多时候可以用来完成复杂条件下的数据查询。比如 ‘in (?,?,?)’, ‘Between 1 and 10’之的条件。 xxQL有着拼装语句可读性差、编译器无法检查、变更维护困难等问题,但是却广受开发人员欢迎。这多少有历史原因,也有Criteria API设计上过于复杂的因素。两者一方是极端灵活但维护困难,一方是严谨强大而学习和编繁琐,两边都是极端。事实上JPA的几种数据查询方式存在青黄不接的问题。选择查询语言xxQL,项目面临后续维护困难,跨数据库移植性差;选择Criteria API,代码臃肿,操作繁琐,很多人望而却步。EF的设计思想是使人早日摆脱拼装SQL/HQL/JPQL的困扰,而是用(更精简易用的)Criteria API来操作数据库。 基于轻量级Criteria API的操作方式,使得对数据库的变更和重构变得非常轻松,解决了SQL语句多对软件维护和移植造成产生的不利影响。 阅读推荐:第3、4章 特点二,将SQL的使用发挥到极致,解决SQL拼凑问题、数据库移植问题 大部分OLTP应用系统到最后都不免要使用SQL/JPQL,然而没有一个很好的方法解决SQL在多种数据库下兼容性的问题。 EF-ORM中采用了独特的SQL解析和改技术,能够主动检查并确保SQL语句或者SQL片段在各个数据库上的兼容性。 EF中除了Criteria API以外,可以直接使用“SQL语句”或者“SQL片段”。但是这些SQL语句并不是直接传送给JDBC驱动的,而是 有着一个数据库方言层,经过方言层处理的SQL语句,就具备了在当前数据库上正确操作的能力。这相当于提供了一种能跨数据库操作的SQL语言。(E-SQL) E-SQL不但解决了异构数据库的语法问题、函数问题、特殊的法问题,还解决了动态SQL问题、绑定变量扩展等特性。 对于各种常用SQL函数和运算符,都可以自动转换为当前数据库支持的方言来操作。其函数支持也要多于HQL支持的函数。 阅读推荐:第7、8章 特点三,可能是业界最快的ORM框架. 得益于ASM的动态代码生成技术,部分耗时操作通过动态代码固化为硬编码实现,EF-ORM的大部分操作性能要超过已知的其他框架。 实际性能测试表明,EF的大部分操作都要快于Hiberante和MyBatis, 部分操作速度甚至数十倍于上述框架EF在极限插入模式下,甚至刷新了每秒10万条入的记录。远远超过了其他框架。 一个初步的性能测试:测试代码:http://geequery.github.io/ef-orm/manual/performance-test.rar 测试报告:http://geequery.github.io/ef-orm/manual/performance-compare.docx 阅读推荐:第9、17章 特点四,分库分表 开发过程中参照了Hibernate Shards、Alibaba TDDL、Cobar等框架,也是基于词法分析器来提取SQL参数,并计算路由。 能支持分库维度含糊等场景下的分库分表。以及包括多库多表下的 order by , distinct, group by, having等操作。 阅读推荐:第10章 特点五,常用DDL操作的封装 从数据库元数据访问,到建表,创建约束,创建sequence等各种DDL操作进行了封装,用户无需编各种SQL,可以直接通过API操作数据库结构。 尤其是ALTER TABLE等修改数据库的语句,各种不同的RDBMS都有较大语法差异。特点六、解决各种跨RDBMS的移植问题 1、DML操作、自增值处理与返回、查询这些不同数据库操作差异很大的东西,都了统一的封装。 2、DDL操作、建表、删表、trunacte,Sequence创建和TABLE模拟Sequence等,都做了支持。 3、对SQL语法操作和函数的改与支持。其他特性轻量 该框架对应用环境、连接池、 是否为J2EE应用等没有特殊要求。可以和EJB集成,也可与Spring集成,也可以单独使用。整个框架只有两个JAR包,模块和功能都较为轻量。依赖少 整个框架只有三个jar库。间接依赖仅有commons-lang, slf4j等7个通用库,作为一个ORM框架,对第三方依赖极小。简单直接的API 框架的API设计直接面向数据库操作,不绕弯子,开发者只需要数据库基本知识,不必学习大量新的操作概念即可使用API完成各种DDL/DML操作。 最大限度利用编译器减少编码错误的可能性 API设计和元数据模型(meta-model)的使用,使得常规的数据库查询都可以直接通过Criteria API来完成,无需使用任何JPQL/HQL/SQL。可以让避免用户犯一些语法、拼等错误。JPA2规范兼容 使用JPA 2.0规范的标准注解方式来定义和操作对象。(但整个ORM不是完整的JPA兼容实现)更高的性能 依赖于ASM等静态字节码技术而不是CGlib,使得改善了代理性能;依赖于动态反射框架,内部数据处理上的开销几乎可以忽略。操作性能接近JDBC水平。对比某H开头的框架,在操作上大约领先30%,在大量数据读取上领先50%以上。更多的性能调优手段 debug模式下提供了大量性能日志,帮您分析性能瓶颈所在。同时每个查询都可以针对batch、fetchSize、maxResult、缓存、级联操作型等进行调整和开关,可以将性能调到最优。可在主流数据库之间任意切换 支持Oracle、MySQL、Postgres、MSSQL、GBase、SQLite、HSQL、Derby等数据库。除了API方式下的操作能兼容各个数据库之外,就连SQL的本地化查询也能使之兼容。JMX动态调节 可以用JMX查看框架运行统计。框架的debug开关和其他参数都可以使用JMX动态调整。动态表支持 表结构元数据的API也向用户开放,同时支持在使用过程中,灵活调整映射关系,因此用户可以用API动态的创建表结构的模型,从而实现各种动态型和表的映射(例如POJO中包含一个Map,用于映射各种动态扩展的字段)企业级特性支持 SQL分析,性能统计,分库分表,Oracle RAC支持,读分离支持 标签:eform
NFine快速开发框架源码 源码描述: 一、源码特点 1、NFine 是基于 C# 语言的极速 WEB + ORM 框架,其核心设计目标是开发迅速、代码量少、学习简单、功能强大、轻量级、易扩展,让Web开发更迅速、简单。能解决60%重复工作。为您节约更多时间,去陪恋人、家人和朋友。轻松开发,专注您的业务,从NFine开始。 二、菜单功能 1、NFine是一套基于 ASP.NET MVC+EF6+Bootstrap 开发出来的框架,源代码完全开源,可以帮助你解决C#以及.NET 项目68%的重复工作,让开发人员远离加班。 2、使用 Apache License 2.0 协议,采用主流框架,容易上手,简单易学,学习成本低。可完全实现二次开发、基本满足80%项目需求。 3、可以帮助解决 .NET 项目70%的重复工作,让开发更多关注业务逻辑。既能快速提高开发效率,帮助公司节省人力成本,同时又不失灵活性。 4、支持 SQLServer、MySQL、Oracle、SQLite、Access 等多数据库型。模块化设计,层次结构清晰。内置一系列企业信息管理的基础功能。 5、操作权限控制精密细致,对所有管理链接都进行权限验证,可控制到导航菜单、功能按钮。 6、数据权限(精细化数据权限控制,控制到行级,列表级,表单字段级,实现不同人看不同数据,不同人对同一个页面操作不同字段 7、提高开发效率及质量。常用封装,日志、缓存、验证、字典、文件、邮件、,Excel。等等,目前兼容浏览器(IE8+、Chrome、Firefox、360浏览器等) 8、适用范围:可以开发 OA、ERP、BPM、CRM、WMS、TMS、MIS、BI、电商平台后台、物流管理系统、快递管理系统、教务管理系统等各管理软件 NFine技术介绍: 1、前端技术 JS框架:jquery-2.1.1、Bootstrap.js、JQuery UI CSS框架:Bootstrap v3.3.4(稳定是后台,UI方面根据需求自己升级改造吧)。 客户端验证:jQuery Validation Plugin 1.9.0。 在线编辑器:ckeditor、simditor 上传文件:Uploadify v3.2.1 动态页签:Jerichotab(自己改造) 数据表格:jqGrid、Bootstrap Talbe 对话框:layer-v2.3 下拉选择框:jQuery Select2 树结构控件:jQuery zTree、jQuery wdtree 页面布局:jquery.layout.js 1.4.4 图表插件:echarts、highcharts 日期控件: My97DatePicker 2、后端技术 核心框架:ASP.NET MVC5、WEB API 持久层框架:EntityFramework 6.0 定时计划任务:Quartz.Net组件 安全支持:过滤器、Sql注入、请求伪造 服务端验证:实体模型验证、自己封装Validator 缓存框架:微软自带Cache、Redis 日志管理:Log4net、登录日志、操作日志 工具:NPOI、Newtonsoft.Json、验证码、丰富公共似 三、注意事项 1、开发环境为Visual Studio 2012,数据库为SqlServer2008R2,使用.net 4.5开发。 2、数据库文件在DB文件夹中

110,551

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧