LLILC详解，基于LLVM的.NET Core编译器

0顶
0踩

2015-04-15 10:00 by 副主编 mengyidan1988 评论(0) 有3284人浏览

LLILC .net

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

介绍

LLILC由JIT和AOT编译器组成，是基于LLVM的.NET Core编译器。目的是创建一组跨平台.NET代码生成工具。LLILC是一个将msIL (.NET)代码编写进本地二进制的开源项目，使用LLVM框架。

支持平台

支持Windows、Linux与Mac OS X

对于Windows，所有命令都从一个Windows命令提示符输入，并且c:\dotnet可能会取代您所选择目录下面的所有命令。准备工作点此查看。

对Linux和OS X的支持仍处于早期阶段。所以这里的推荐流程会显得粗糙些，点此查看。

开发环境和测试工具

开发环境和回归测试工具的创建是用来帮助标准化一些常见的开实践和提供回归测试能力，脚本位于LLILC\test\LLILCEnv.ps1。

1.先决条件

安装以下软件：Visual Studio 12.0、Git、CMake、Python、GnuWin32和DiffMerge
创建LLVM与LLILC本地存储库
一个用于LLVM构建目录的默认位置
在引擎盖下，LLICL使用CoreCLR的测试资源，并且一个CoreCLR运行时与LLILC JIT匹配
2.环境初始化

创建一个快捷方式，例如：C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -nologo -noexit -executionpolicy remotesigned -c . { C:\yourpathto\LLILC-init.ps1 Ret title "LLILC Term" }
LLILC-init.ps1自定义环境变量，如果LLILC资源在tree中，它最终应该调用“& $Env:LLVMSOURCE\tools\LLILC\test\LLILCEnv.ps1”，如果在tree外，则调用“& $Env:LLILCSOURCE\test\LLILCEnv.ps1”。
LLILCEnv.ps1验证你的软件安装和环境变量。它会完成其余开发环境和测试工具的设置，包括获取或更新CoreCLR测试资产等。
测试创建、用例等更多细节点此查看。

贡献

LLILC刚刚建起来，目前只有几个测试工具，还有很多地方需要得到支持。GitHub上的地址点此进入。

文档

1.开发者指南

Windows准备指南
Linux与OS X准备指南
构建与测试
贡献指南
LLILC编码常规和注释风格
2.结构

LLILC结构概览
3.在LLVM支持的管理结构

LLILC MSIL阅读器
LLILC中的GC支持
LLILC中的EH支持
4.其他资源

dotnet/CoreCLR
dotnet/CoreFx

分享到：

0
顶

0
踩

评论共 0 条请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

AppFramework数据库访问组件_代码生成插件_V1.1.rar

V1.1比V1.0增强了IDBSession功能，可查询得到 IDataReader；修改了查询 in 操作符的bug。 内含代码生成器，支持Oracle/SqlServer/MSAccess，ORMap性能大大优于iBatisNet,终身免费无限制使用，绝无任何版权问题。 =========== 软件说明： 1.1 引言 约有90%的企业信息化管理系统基于数据库实现，这类系统中又有超过30%的代码集中在数据访问层负责业务数据存取。除了实现数据的增删改查，数据访问层还要提供一些与业务无关功能，例如面向对象的持久化与访问机制、本地事务与分布式事务支持、多数据库支持，这些机制或功能形成相对独立的逻辑领域，其主要目的有： 1、提供简单易用的数据库访问方法，提高开发效率； 2、提供面向对象的方式来简化对数据库访问与操作，也就是ORMap方式； 3、屏蔽数据库差异，使开发出的产品容易在不同数据库产品上移植。 为了适应软件快速开发的需要，软件企业应该借助组件产品或开源软件项目来搭建这些基础设施。在.Net平台上，目前比较成功和应用较广的开源项目有NHibernate和IBatisNet等，它们在ORMap方面的表现尤为突出。依赖这些平台，软件开发效率和产品质量都得到了极大提高，ORMap机制渐渐成为大势所趋。 本公司致力于软件组件开发，提供的AppFramework数据库访问组件具有高效的ORMap机制，调用接口简单灵活，支持各种主流的数据库平台，是个非常优秀的数据访问组件。本文详尽描述了AppFramework数据库访问组件使用的方法和技巧，有助于开发者最大程度发挥出AppFramework的优势。 1.2 各种优秀ORMap工具比较 NHibernate和IBatisNet等虽然都实现了ORMap，但它们的设计侧重点有所不同，有着各自的优势和缺陷，适合于特定的项目。NHibernate实现了纯对象化的ORMap，在屏蔽数据库差异、面向对象方面做的非常好，但在访问与操作海量数据时其性能表现较差，也不易实现复杂的查询统计功能。NHibernate适合那些数据量不大、性能要求不高、复杂度不高的场合。 IBatisNet是一个轻量级ORMap工具，它把所有的SQL脚本以模板的方式集中到若干个XML配置文件里，用反射的方式向把C#类实体对象属性与SQL模板的参数绑定，动态生成参数化的SQL语句发送给数据库执行，查询的结果集也用反射的方式构造为对象集合返回给程序。由于提供了灵活的SQL模板机制，在海量数据的访问与操作方面其性能比NHibernate要高得多，也很容易实现各种复杂的数据查询统计功能。但是IBatisNet也存在许多几个不足之处，有些还是先天因素造成的： 第一，数据库可移植性差。IBatisNet获得高性能与灵活性也是付出代价的，它牺牲了数据库可移植性：由于编写SQL模板不得不用到数据库产品的一些语法差异，例如ORACLE的TO_DATE、Length()、SYSDATE等，为了把产品移植到其它数据库，开发人员不得不对大量的SQL模板进行翻译。 第二，无法方便地向数据库中插入NULL值。因为IBatisNet是直接把C#的基本类型(如int/DateTime)插入到数据库中字段的。对于一些C#值类型，例如int，并没有NULL状态。于是不得不采用一些特殊的值来表示NULL，例如int.MinValue。IBatisNet数据映射器会自动把int.MinValue转换为NULL插入到数据库，而从数据库中获得NULL时，也会转化为C#的int.MinValue。这样，程序就要对int.MinVaue这个值进行特殊处理，例如不能把int.MinValue直接显示在DataGrid里或界面上。有一种规避的方法，就是避免向数据库插入NULL，即要求所有业务数据入库的值都不为空。但这样作实际上是限制了程序的行为能力，例如无法实现单据草稿的保存。 第三，在插入数据时无法方便的使用字段默认值。最明显的就是类似于LAST_UPDATE_TIME了，通常为了保证这个字段的一致性，通常在插入新记录时采用当前数据库时间作为字段值。但IBatisNet接收的实体类对象属性都是普通C#类型，并不具备传入表达式的能力。如果采用动态SQL，则会导致SQL模板和参数实体类过于复杂，将极大降低性能。 第四，在查询返回大量对象时，用反射的方式构造实体的方式性能损失是相当大的。实体类属性数目越多、返回记录数越多，用到反射的次数也越多，查询性能降低就越明显。 第五，不能方便地限定查询语句返回的字段。ADO.Net执行查询时，select语句里设置了几个字段就返回几个字段到DataTable。而IBatisNet若要返回不同的字段就要定义多套ResultMap，否则就定义一套所有字段的ResultMap，任何查询都返回所有字段。这样无疑浪费了数据库服务器与应用服务器之间的网络带宽，在进行海量数据访问时性能将严重降低。 第六，返回的结果IList不能够方便地进行二次查询。相比之下，ADO.Net返回的DataTable虽然性能差一些，但可以实现在应用程序内存中灵活和高性能的二次查询。 第七，无法直接利用数据库的特殊语法支持海量数据的分页查询功能。众所周知Oracle提供了ROWNUM实现数据数据库内分页功能，若要利用这一特性，就要在SQL模板里直接硬编码这些特殊语法，这必然导致大量的移植工作。 第八、缺少代码生成和检查工具。程序里的变量名与Sql模板里的变量经常会出现不一致，而这些错误无法在编译时发现，靠人工检查很容易造成错误泄漏。也没提供工具直接生成SQL模板和映射配置文件。 第九，IBatisNet的SqlMap文件里的SQL语句以明文存放，容易被修改造成重大安全隐患，尤其不适合开发C/S应用程序。 第十，由于Sql模板采用动态加载的方式，如果写错了SQL，程序里难以跟踪调试，这对初学者来说无疑是对耐心和信心的极大考验。 总之，IBatisNet虽然提灵活、高性能的ORMap机制，但却损失了数据库可移植性的，在使用方便性和局部性能方面也都有很大提高的余地。 1.3 AppFramework数据访问组件的组成和优势 AppFramework数据访问组件由下列文件组成： 1、 AppFramework.DBAccess.dll 提供多数据库统一的访问接口，提供DAO管理器、数据库会话管理器。 2、 AppFramework.Data.dll 提供核心的数据结构和基础类。 3、 AppFramework.Tools.CodeGenPlugin.msi 提供集成于Visual Studio 2005的C#代码生成器插件，用于生成DAO/Model/各种接口。 4、 DBAccess.config 配置数据库连接串。 5、 CodeGenPlogin.config 配置代码生成器参数。 6、 *.DaoGen文件 配置DAO生成信息，并由CodeGenPlugin解析生成代码。 AppFramework数据库访问组件针对IBatisNet的种种缺陷提出相应的解决方案，相比之下有如下优势： 1、从扩展基础数据类型入手，解决了空值问题和默认值问题； 2、提供了内置的数据库内分页访问机制，极大地提高了海量查询的响应速度； 3、增加ObjectTable<T>泛型类来承载查询返回的对象集，不但比IList更加强类型化，还提供了二分查找功能，使得对象结果集可以在应用程序内存中进行重排序和快速查找； 4、提供了强大的QueryFilter类构造查询条件，使得实现数据查询不再需要编写复杂的SQL语句； 5、提供类似IBatisNet的Sql模板功能，为复杂的查询统计提供较直观的开发模式； 6、提供代码生成工具，生成的类代码的同时可以类之间的继承关系和接口实现关系，所有DAO类方法均以接口作为参数，使得代码更加具有可扩展性和灵活性。 7、 Sql模板和ORMap直接生成.cs原代码，编译为可执行代码，各种ORMap映射文件无需再随主程序集一起部署，提高了代码的安全性，提高了代码的可调试性，也提高了ORMap的性能。 下面三张表格罗列的测试数据，可以明显看出AppFramework数据库访问组件的性能全面超越了IBatisNet： 表I –10并发20循环（数据库和测试机分开） 对比项目 iBatis2.0 （毫秒） AppFramework （毫秒） 后者前者性能对比 （倍） 根据主键获取实体 (20次单条select) 19.8 16.1 QueryFilter:18.0 1.23 1.10 每秒插入实体 (20次insert) 41 21 1.95 更新实体 (20次单条update) 27 19 SqlMap:24 1.42 1.13 查询结果集（平均101行） (2循环200次select) 1100 690 不定字段:720 1.59 1.53 表II –50并发4循环（数据库和测试机分开） 对比项目 iBatis2.0 （毫秒） AppFramework （毫秒） 后者前者性能对比 （倍） 根据主键获取实体 (20次单条select) 17.5 13.3 QueryFilter:14.5 1.32 1.21 插入实体 (20次insert) 36.1 17.4 2.07 更新实体 (20次单条update) 23.5 15.9 SqlMap:20.3 1.48 1.16 查询结果集（平均101行） (1循环200次select) 1055.1 666.8 不定字段:710.1 1.58 1.50 表III –50并发10循环（数据库和测试机同机） 对比项目 iBatis2.0 （毫秒） AppFramework （毫秒） 后者前者性能对比 （倍） 根据主键获取实体 (20次单条select) 6.1 5.3 QueryFilter: 5.75 1.15 1.06 插入实体 (20次insert) 15.1 10.8 1.40 更新实体 (20次单条update) 10.4 7.5 SqlMap:9.3 1.38 1.12 查询结果集（平均101行） (1循环200次select) 560 360 不定字段:380 1.56 1.47 总之，AppFramework数据库访问组件是一个高性能、接口简单、可移植性强、高灵活性的综合数据访问解决方案。使用AppFramework数据库访问组件，可以降低企业的开发人员培训成本，提高产品的开发速度，提高产品稳定可靠性，提高产品的可伸缩性和可移植性。下文将分入门、精通、高级三个篇章，详细讲述如何使用AppFramework数据库访问组件来搭建应用程序。

AppFramework_V1.0

1.1 引言 约有90%的企业信息化管理系统基于数据库实现，这类系统中又有超过30%的代码集中在数据访问层负责业务数据存取。除了实现数据的增删改查，数据访问层还要提供一些与业务无关功能，例如面向对象的持久化与访问机制、本地事务与分布式事务支持、多数据库支持，这些机制或功能形成相对独立的逻辑领域，其主要目的有： 1、提供简单易用的数据库访问方法，提高开发效率； 2、提供面向对象的方式来简化对数据库访问与操作，也就是ORMap方式； 3、屏蔽数据库差异，使开发出的产品容易在不同数据库产品上移植。 为了适应软件快速开发的需要，软件企业应该借助组件产品或开源软件项目来搭建这些基础设施。在.Net平台上，目前比较成功和应用较广的开源项目有NHibernate和IBatisNet等，它们在ORMap方面的表现尤为突出。依赖这些平台，软件开发效率和产品质量都得到了极大提高，ORMap机制渐渐成为大势所趋。 本公司致力于软件组件开发，提供的AppFramework数据库访问组件具有高效的ORMap机制，调用接口简单灵活，支持各种主流的数据库平台，是个非常优秀的数据访问组件。本文详尽描述了AppFramework数据库访问组件使用的方法和技巧，有助于开发者最大程度发挥出AppFramework的优势。 1.2 各种优秀ORMap工具比较 NHibernate和IBatisNet等虽然都实现了ORMap，但它们的设计侧重点有所不同，有着各自的优势和缺陷，适合于特定的项目。NHibernate实现了纯对象化的ORMap，在屏蔽数据库差异、面向对象方面做的非常好，但在访问与操作海量数据时其性能表现较差，也不易实现复杂的查询统计功能。NHibernate适合那些数据量不大、性能要求不高、复杂度不高的场合。 IBatisNet是一个轻量级ORMap工具，它把所有的SQL脚本以模板的方式集中到若干个XML配置文件里，用反射的方式向把C#类实体对象属性与SQL模板的参数绑定，动态生成参数化的SQL语句发送给数据库执行，查询的结果集也用反射的方式构造为对象集合返回给程序。由于提供了灵活的SQL模板机制，在海量数据的访问与操作方面其性能比NHibernate要高得多，也很容易实现各种复杂的数据查询统计功能。但是IBatisNet也存在许多几个不足之处，有些还是先天因素造成的： 第一，数据库可移植性差。IBatisNet获得高性能与灵活性也是付出代价的，它牺牲了数据库可移植性：由于编写SQL模板不得不用到数据库产品的一些语法差异，例如ORACLE的TO_DATE、Length()、SYSDATE等，为了把产品移植到其它数据库，开发人员不得不对大量的SQL模板进行翻译。 第二，无法方便地向数据库中插入NULL值。因为IBatisNet是直接把C#的基本类型(如int/DateTime)插入到数据库中字段的。对于一些C#值类型，例如int，并没有NULL状态。于是不得不采用一些特殊的值来表示NULL，例如int.MinValue。IBatisNet数据映射器会自动把int.MinValue转换为NULL插入到数据库，而从数据库中获得NULL时，也会转化为C#的int.MinValue。这样，程序就要对int.MinVaue这个值进行特殊处理，例如不能把int.MinValue直接显示在DataGrid里或界面上。有一种规避的方法，就是避免向数据库插入NULL，即要求所有业务数据入库的值都不为空。但这样作实际上是限制了程序的行为能力，例如无法实现单据草稿的保存。 第三，在插入数据时无法方便的使用字段默认值。最明显的就是类似于LAST_UPDATE_TIME了，通常为了保证这个字段的一致性，通常在插入新记录时采用当前数据库时间作为字段值。但IBatisNet接收的实体类对象属性都是普通C#类型，并不具备传入表达式的能力。如果采用动态SQL，则会导致SQL模板和参数实体类过于复杂，将极大降低性能。 第四，在查询返回大量对象时，用反射的方式构造实体的方式性能损失是相当大的。实体类属性数目越多、返回记录数越多，用到反射的次数也越多，查询性能降低就越明显。 第五，不能方便地限定查询语句返回的字段。ADO.Net执行查询时，select语句里设置了几个字段就返回几个字段到DataTable。而IBatisNet若要返回不同的字段就要定义多套ResultMap，否则就定义一套所有字段的ResultMap，任何查询都返回所有字段。这样无疑浪费了数据库服务器与应用服务器之间的网络带宽，在进行海量数据访问时性能将严重降低。 第六，返回的结果IList不能够方便地进行二次查询。相比之下，ADO.Net返回的DataTable虽然性能差一些，但可以实现在应用程序内存中灵活和高性能的二次查询。 第七，无法直接利用数据库的特殊语法支持海量数据的分页查询功能。众所周知Oracle提供了ROWNUM实现数据数据库内分页功能，若要利用这一特性，就要在SQL模板里直接硬编码这些特殊语法，这必然导致大量的移植工作。 第八、缺少代码生成和检查工具。程序里的变量名与Sql模板里的变量经常会出现不一致，而这些错误无法在编译时发现，靠人工检查很容易造成错误泄漏。也没提供工具直接生成SQL模板和映射配置文件。 第九，IBatisNet的SqlMap文件里的SQL语句以明文存放，容易被修改造成重大安全隐患，尤其不适合开发C/S应用程序。 第十，由于Sql模板采用动态加载的方式，如果写错了SQL，程序里难以跟踪调试，这对初学者来说无疑是对耐心和信心的极大考验。 总之，IBatisNet虽然提灵活、高性能的ORMap机制，但却损失了数据库可移植性的，在使用方便性和局部性能方面也都有很大提高的余地。 1.3 AppFramework数据访问组件的组成和优势 AppFramework数据访问组件由下列文件组成： 1、 AppFramework.DBAccess.dll 提供多数据库统一的访问接口，提供DAO管理器、数据库会话管理器。 2、 AppFramework.Data.dll 提供核心的数据结构和基础类。 3、 AppFramework.Tools.CodeGenPlugin.msi 提供集成于Visual Studio 2005的C#代码生成器插件，用于生成DAO/Model/各种接口。 4、 DBAccess.config 配置数据库连接串。 5、 CodeGenPlogin.config 配置代码生成器参数。 6、 *.DaoGen文件 配置DAO生成信息，并由CodeGenPlugin解析生成代码。 AppFramework数据库访问组件针对IBatisNet的种种缺陷提出相应的解决方案，相比之下有如下优势： 1、从扩展基础数据类型入手，解决了空值问题和默认值问题； 2、提供了内置的数据库内分页访问机制，极大地提高了海量查询的响应速度； 3、增加ObjectTable<T>泛型类来承载查询返回的对象集，不但比IList更加强类型化，还提供了二分查找功能，使得对象结果集可以在应用程序内存中进行重排序和快速查找； 4、提供了强大的QueryFilter类构造查询条件，使得实现数据查询不再需要编写复杂的SQL语句； 5、提供类似IBatisNet的Sql模板功能，为复杂的查询统计提供较直观的开发模式； 6、提供代码生成工具，生成的类代码的同时可以类之间的继承关系和接口实现关系，所有DAO类方法均以接口作为参数，使得代码更加具有可扩展性和灵活性。 7、 Sql模板和ORMap直接生成.cs原代码，编译为可执行代码，各种ORMap映射文件无需再随主程序集一起部署，提高了代码的安全性，提高了代码的可调试性，也提高了ORMap的性能。 下面三张表格罗列的测试数据，可以明显看出AppFramework数据库访问组件的性能全面超越了IBatisNet： 表I –10并发20循环（数据库和测试机分开） 对比项目 iBatis2.0 （毫秒） AppFramework （毫秒） 后者前者性能对比 （倍） 根据主键获取实体 (20次单条select) 19.8 16.1 QueryFilter:18.0 1.23 1.10 每秒插入实体 (20次insert) 41 21 1.95 更新实体 (20次单条update) 27 19 SqlMap:24 1.42 1.13 查询结果集（平均101行） (2循环200次select) 1100 690 不定字段:720 1.59 1.53 表II –50并发4循环（数据库和测试机分开） 对比项目 iBatis2.0 （毫秒） AppFramework （毫秒） 后者前者性能对比 （倍） 根据主键获取实体 (20次单条select) 17.5 13.3 QueryFilter:14.5 1.32 1.21 插入实体 (20次insert) 36.1 17.4 2.07 更新实体 (20次单条update) 23.5 15.9 SqlMap:20.3 1.48 1.16 查询结果集（平均101行） (1循环200次select) 1055.1 666.8 不定字段:710.1 1.58 1.50 表III –50并发10循环（数据库和测试机同机） 对比项目 iBatis2.0 （毫秒） AppFramework （毫秒） 后者前者性能对比 （倍） 根据主键获取实体 (20次单条select) 6.1 5.3 QueryFilter: 5.75 1.15 1.06 插入实体 (20次insert) 15.1 10.8 1.40 更新实体 (20次单条update) 10.4 7.5 SqlMap:9.3 1.38 1.12 查询结果集（平均101行） (1循环200次select) 560 360 不定字段:380 1.56 1.47 总之，AppFramework数据库访问组件是一个高性能、接口简单、可移植性强、高灵活性的综合数据访问解决方案。使用AppFramework数据库访问组件，可以降低企业的开发人员培训成本，提高产品的开发速度，提高产品稳定可靠性，提高产品的可伸缩性和可移植性。下文将分入门、精通、高级三个篇章，详细讲述如何使用AppFramework数据库访问组件来搭建应用程序。

支持多数据库的ORM框架ef-orm.zip

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

数据库设计，讲解业务实体对象到数据库表的映射关系。

业务对象到关系数据库映射的若干模式（2）

动机：试想你有一个Patient类，有Name和Address部件，当你读取一个Patient，必须同时读取Name和Address。写入一个Patient到数据库中将有可能写入一个Name和Address对象。他们是否有同样的接口去读取和写入呢？也许有些对象需要不同的接口？我们能否给出完全同样的接口，如果可以，是什么? 任何被持久化的对象都要对数据库进行读取和写入，对新创建的对象，它的值也会被

企业项目设计工具教程篇：如何执行业务流程映射

Visual Paradigm是包含设计共享、线框图和数据库设计新特性的企业项目设计工具。Visual Paradigm公司在其核心产品Visual Paradigm for UML更新到v11.1的时候，把三个原始的系列产品（Agilian、Visual Paradigm for UML和Logizian）融合在一起，将最初为不同建模功能服务的多个独立产品整合成的一个产品，其名字被命名为Visual Paradigm——与公司的名字相同。现在你只需要这样单独的一款模型软件 Visual Paradigm就

领域驱动设计--业务架构映射为应用架构(五)

通过《多维度规划业务架构》，我们获得了由业务领域-业务组件-业务服务三个层次组成的业务架构。虽然是架构，但其本质仍然属于问题空间，其目的在于真实地探索问题空间，了解我们要解决什么样的问题。我们用到“分解”的方法，并非在解决问题，而是希望通过横向分层与纵向切分让问题空间变得更小，降低业务复杂度罢了。这种分解层次体现为：业务领域是对目标系统之系统范围进行划分，划分依据为价值高低业务组件是对业务领域的划分，划分依据在于业务相关性业务服务是对业务组件的划分，划分依据在于领域模

通过利用“业务映射”来构建敏捷组织

Dan North此前在比利时布鲁塞尔举办的Scaling Agile for the Enterprise 2016大会上谈到了关于业务映射的相关内容，随后InfoQ采访了Dan North，从商业角度来看，IT部门的各个组织采用敏捷开发过程中遇到的那些问题。Dan North也介绍了什么是业务映射，以及它如何帮助组织提高敏捷性和灵活性。\\InfoQ：能不能从商业角度来阐述一下IT组织在采纳敏...

业务对象功能授权模块找不到对应的业务对象

需要在权限控制设置->勾选"控制功能权限" 转载于:https://www.cnblogs.com/zouhuaxin/p/10383252.html

对象关系映射SQLAalchemy

什么是ORM? ORM，即Object-Relational Mapping（对象关系映射），它的作用是在关系型数据库和业务实体对象之间作一个映射，这样，我们在具体的操作业务对象的时候，就不需要再去和复杂的SQL语句打交道，只需简单的操作对象的属性和方法。 SQLAlchemy 是Python编程语言下的一款开源软件。提供了SQL工具包及对象关系映射（ORM）工具，为高效和高性能的数据库访问...

T-Cont

T-CONT（Transmission Container）是GPON上行方向承载业务的载体，所有的GEM Port都要映射到T-CONT中，由OLT通过DBA（Dynamic Bandwidth Allocation）调度的方式上行。（T-CONT是DBA的上行流量调度单位，即业务容器。）T-CONT是DBA实现的基础，通过ONU对T-CONT的带宽申请、OLT对T-CONT的授权，实现整个GP...

数字化转型.观点：战略溯源、业务映射、系统变革、直击价值、能力底座

数字化转型是系统性工程和全局性变革，当前数字化转型模式远未定型仍在摸索实验路上，为了更深度地探讨数字化转型，和创讯为组织撰写数字化转型观点、角度、目标的系列文章，抛砖引玉供大家参考，笔者水平有点，文中不足不妥之处敬请海涵，希望与各位奋战在数字化转型实践者相互交流、共同成长。本文是系列文章之一的核心观点篇，侧重探讨数字化转型的定位以及与战略规划、业务拓展和经营管理的关系和价值体现。观点1 数字化溯源是战略，在数字世界中重构物理世界数字化转型一定是组织级战略而非部门级或职能级战略，数字化是企业

业务架构映射-1 之业务能力模型映射

业务能力模型，即 Business Capability Model，的映射可以说业务架构映射的核心中核心。这个映射流程可以告诉我们一个业务到底在做的是什么，即其核心能力，其要实现的目标，即主要是WHAT的问题。我之前整理过ArchiMate标准中的一个参考资料-ArchiSurance-的建模实践。

前后端业务枚举映射问题解决方案

前后端业务枚举映射问题解决方案这个问题其实和我们遇到的时间格式转换类似。数据库存储业务标识为方便计算或判断，多为数字或字母，这类数据在返回给前端做展示的时候，需要转换成对应的业务标识说明，如币种在数据库中可能存储 CNY，实际我们展示的时候，有可能需要将其转成中文人民币来进行展示，这时，便有了前后端业务枚举映射的问题。方案建议这里我列举一些可行的方案建议，并对其简要说明优缺点，仅供参考方案一：前端转义前端负责全部转义职责，解决思路很简单，将所有数据库保存的值直接返回给前端，前端根

设计数据层组件并在层间传递数据(好文收藏)

设计数据层组件并在层间传递数据Angela Crocker、Andy Olsen 和 Edward JezierskiMicrosoft Corporation 2002年8月适用于： Microsoft® .NET 应用程序摘要：学习向 Microsoft .NET 应用程序公开数据的最佳方式，以及如何实现一个有效的策略以便在分布式应用程序的层间传递数据。（本文包含一些指向英

Oracle数据库创建实体对象，在自命名包中定义函数以及返回实体对象数据

select fpdm,dsfjdm from tfp_fplx where dsfjdm='13701'; --创建测试实体 create or replace type testObject as object ( fpdm varchar2(20), dsfjdm varchar2(20) ) //分布执行，先执行上面的，在执行下面的 --创建一个表，表中的每一条记录都是上面

第 6 章对象/关系数据库映射基础(Basic O/R Mapping)

6.1. 映射定义（Mapping declaration）对象和关系数据库之间的映射通常是用一个XML文档(XML document)来定义的。这个映射文档被设计为易读的，并且可以手工修改。映射语言是以Java为中心，这意味着映射文档是按照持久化类的定义来创建的，而非表的定义。请注意，虽然很多Hibernate用户选择手写XML映射文档，但也有一些工

数据库—02对象关系映射sqlalchemy

一、简介 ORM，即Object-Relational Mapping（对象关系映射），它的作用是在关系型数据库和业务实体对象之间作一个映射，这样，我们在具体的操作业务对象的时候，就不需要再去和复杂的SQL语句打交道，只需简单的操作对象的属性和方法。简单地说，就是把面向对象的语言翻译成SQL语句并执行。 SQLAlchemy是Python编程语言下的一款开源软件。提供了SQL工具包及对象关系...

领域模型和数据库表结构对应关系

以前我自己做过的项目中和别人的项目中都有这样的一些定论，就是往往先设计数据库表模型，然后根据表产生业务逻辑模型。譬如，在数据库中有一个表T_USER，在程序中就会有User类，所以一般情况就一对一的映射关系了。领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领...

resultMap映射数据错误问题

mapper文件使用了resultMap进行一对多关系映射，不管怎么配置（没有问题）SQL语句查询出来的结果，和调用mapper代理对象产生的entry数据就是不一致。解决方案：在mapper的sql语句中加上order by。

0顶0踩