OFBIZ 实体引擎
相关文件:
# 实体引擎配置指南
# 核心配置指南
# JavaDoc表（文件页面）
# XML文件定义（文件页面）
介绍
OFBIZ 实体引擎提供了一组工具和设计模式来对现实世界中特定的实体（数据对象）进行建模和管理。在本系统的上下文环境中，一个实体就是一个由多个数据域（fields）和该实体与其它实体之间的关系所组成的一个数据对象。这个定义来自于关系型数据库对实体关系模型（Entity-Relation modeling）概念的标准定义。实体引擎的目标是简化企业级应用中对实体数据（对应关系型数据库表）的大量操作，包括定义、维护、通用操作（增、删、改、查实体和实体之间的关系）的开发工作。
实体引擎采用了很多被大多数企业级应用系统公认的位于业务逻辑层和集成层（Business Tier and Integration Tier）的设计模式。许多表示层（Presentation Tier）的设计模式也被引入进OFBIZ，但是仅仅体现在Servlet控制器（the servlet controller）中，没有包括在实体引擎中。在实体引擎中使用的设计模式包括：业务代表（Business Delegate），值对象（Value Object）， 符合实体（Composite Entity(variation)），值对象组装器（Value Object Assembler），服务定位器（Service Locator）和数据访问对象（Data Access Object）。OFBIZ正在计划逐步引入其它设计模式和完善已经引入的设计模式的实现。
Descriptions of these patterns are all available in the book "Core J2EE Patterns" by Alur, Crupi, and Malks, published by Sun. You can also find information on these patterns at the site that contains the early work of the authors before the published book was finished. See http://developer.java.sun.com/developer/restricted/patterns/J2EEPatternsAtAGlance.html. Note that you need a Java Developers Connection account to view this information.
In addition there are a number of patterns used from the upcoming book "EJB Design Patterns" by Floyd Marinescu of TheServerSide.com. These include Data Transfer HashMap and Generic Attribute Access. For unique primary key generation we use an original pattern we like to call the "Ethernet Key Generation" pattern because it uses a collision detection mechanism to insure that multiple servers can use a single database to get banks of unique keys in a database independent way.
实体引擎的一个主要目标是尽可能的提供一种通用的代码结构，来消除在针对每一个实体的事物处理过程中，所有写死（hard code）的代码。这种系统抽象所关注的问题，与那些把数据从数据库中提取出来，并以报表的形式进行输出和显示处理的报表管理或类似系统是不同的，而是类似于每日都可能发生很多事物处理的商业应用系统，实体引擎能大量节省构建类似应用系统的开发费用和戏剧性的减少因为系统存在大量写死的事务处理代码所产生的bug。这种类型的应用系统目前在OFBIZ中实现了一些，如电子商务，入库、出库的帐目管理，任务分配资源管理等等。这些工具能够用来报告和分析系统，但是并不意味着，它能包容千差万别的客户的应用需求，在实际应用中，我们可以基于它来做一些二次开发。
为了达到尽可能少的在系统中出现与针对特定实体操作有关的代码，存储实体属性值的对象结构必须设计成通用的，可以用一个MAP对象来存贮实体的所有域（也可以叫字段或属性），通过实体的名称来区分它们是哪个实体的。根据字段的名称，用一个简单操作String数据的方法，来从值对象中读出或写入某字段的值，并且还可以验证给定名称的字段是否是该值对象的一个合法域。在实体引擎和应用系统之间建立了一个约定（体现实体结构定义文件和字段类型、Java数据类型、SQL字段类型映射关系的定义中），这个约定被定义在特定的 XML文件中，以减少这种灵活性可能存在对系统不利的风险（如数据类型问题可能引起数据库系统崩溃等）。
代替不在系统中书写针对特定实体操作的的代码的方法之一，是把实体的定义放在XML文件中，在系统启动的时候，由实体引擎负责把这些结构定义加载进内存，并且在应用程序和数据源（通常指一个数据库或其它资源）之间建立一些对这些定义的使用规则。在这些XML实体定义中，对实体和属于它们的域，以某种规则和数据库中的表和表的字段建立映射关系。而且实体与实体之间的关系，实体域的数据类型，Java语言的数据类型，SQL 数据类型之间的映射关系，也被定义在XML文件中。
实体之间的关系还可以被命名，以用来区分不同实体组合之间的特定关系。
基于实体引擎这个抽象层，与特定实体操作有关的代码的编写就变的很容易创建和修改。 使用实体引擎所提供的APIs，编写处理实体持久性（增、删、改、查）的代码，可以不同的方式来配置，以便于实现针对实体持久性操作（增、删、改、查）有变化时，可以不改变代码本身，因为它并没有写死。这种抽象的一个典型应用场景就是你既可以通过JDBC直连方式，也可以通过调用运行在EJB服务器上的实体Bean（Entity Beans）的方式或者以其它方式，甚至在系统所提供的框架范围内，使用者运用自己扩充的方式去完成对实体持久性的改变等等。这些不同方式的切换并不需要对代码做任何改动，只需要修改配置文件。
实体建模
实体建模 Files & Locations
最初需要做的是，定义或建模，创建一个新的实体，。在OFBiz 实体引擎这做通过二个XML 文件, 一个为实体模型和另一个是字段类型定义。有链接对XML DTDs 为这些文件在 相关文件 部分上面。原因这两个文件被分离是, 字段类型定义是根据具体数据库定义的。换句话说, 为一个指定的个体模型定义各种各样的字段类型定义也许为不同的数据库存在。当坚持服务器被定义字段类型模型XML 文件被使用为那台服务器被指定。
实体模型XML文件能够在 ofbiz/commonapp/entitydef/中找到。所有实体最初是在 entitymodel.xml 文件中定义的, 但他们现在被分离入各种各样的文件除 entitymodel.xml 文件之外。他们全部命名以以下样式: entitymodel_*.xml
MySQL 字段类型模型XML文件为能够找到在 ofbiz/commonapp/entitydef/fieldtypemysql.xml。有其它数据库具体字段类型文件为Postgres, Hypersonic, Oracle, 和cetera 。从实体模型文件和字段类型文件，数据库能自动地被创造通过checkDataSource在GenericHelper 接口。这可能自动地做在执行或通过工具在WebTools 。
装载种子数据
当表自动生成的时候，数据必须由数据文件加载。这些文件可以是SQL脚本或XML实体引擎文件。 All of the type information and other pre-loaded information such as statuses, enumerations, geo data, etc., are located in XML Entity Engine files in ofbiz/commonapp/db/ .所有的类型信息和其他预加载的信息，如状态， enumerations ，地理数据等，分别位于中的XML实体引擎档案ofbiz / commonapp /分贝/ 。 These files can be located and loaded automatically by the install.jsp page in WebTools.这些文件都可以找到并装上自动由install.jsp一页webtools 。 This page looks in the directories specified in the entityengine.xml file for a given entity group name and finds all .xml and .sql files.这页看起来，在指定的目录下，在entityengine.xml立案某个实体组名称，并认为所有。 XML和。 SQL的档案。 These are listed and confirmation is requested by the page.这些都是上市公司及确认书所要求的网页。
点击Yes，将使这些档案，被加载。
错误信息将会出现在网站页面上，以及对控制台或日志文件。
Data files can also be loaded one at a time by specifying the full path of the .sql or .xml file in the load a single file form.
数据文件也可以装在一个时间通过指定全路径的.SQL的还是.XML文件中加载一个单一文件形式。
而关于这个点，XML实体引擎文件还可以导入和导出通过webtools中的import & export页面 。
一个实体定义的例子
如上所述一个实体就是一个由多个数据域（fields）和该实体与其它实体之间的关系所组成的。在XML实体定义上述每所指明的，除了属性的实体本身，如实体的名称，相应的表名，包名为实体，和元数据实体，如作者，版权公告一个描述，等等。这里是一个XML实体定义的例子：
<entity title="Sample Entity"
copyright="Copyright (c) 2001 John Doe Enterprises"
author="John Doe" version="1.0"
package-name="org.ofbiz.commonapp.sample"
entity-name="SampleEntity"
table-name="SAMPLE_ENTITY">
<field name="primaryKeyFieldOne" col-name="PRIMARY_KEY_FIELD_ONE" type="id-ne"></field>
<field name="primaryKeyFieldTwo" type="id-ne"></field>
<field name="fieldOne" type="long-varchar"></field>
<field name="fieldTwo" type="long-varchar"></field>
<field name="foreignKeyOne" type="id"></field>
<prim-key field="primaryKeyFieldOne" />
<prim-key field="primaryKeyFieldTwo" />
<relation type="one" rel-entity-name="OtherSampleEntity">
<key-map field-name="foreignKeyOne" rel-field-name="primaryKeyOne" />
</relation>
<relation type="one" title="Self" rel-entity-name="SampleEntity">
<key-map field-name="primaryKeyFieldOne" />
<key-map field-name="primaryKeyFieldTwo" />
</relation>
<relation type="many" title="AllOne" rel-entity-name="SampleEntity">
<key-map field-name="primaryKeyFieldOne" />
</relation>
</entity>
这是一个非常简单的实体，仅仅显示了几个点。在顶部的元数据是所有可选的，如果没有指定值将使用缺省的元数据定义整个实体模型文件。包名是用来管理实体，可为任何代码指定一个默认位置将实体的实例化。当一个entity model有许多的实体时，这成为非常有用的。
实体和字段定义
注意：字段primarykeyfieldone指定了一个column名称，其他字段没有指定的。 The col-name and the table-name elements are optional.col-name和table-name元素是可选的。它们可以由entity name或field name，自动生成。这些自动生成极大简化定义实体的操作。
表名和列名都是用下划线区分的，例如SAMPLE_ENTITY 。
实体名和字段名都可以利用Java转换为java类名和字段名，Class变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。实体名对应的Java类名，所以第一个字母是大写，但字段名对应类的一个字段，所以第一个字母是小写。
例如： SampleEntity和fieldOne 对应 SAMPLE_ENTITY和FIELD_ONE 。
复合主键，可以使用多个<prim-key>标签指定字段为主键。
字段类型是指定字段使用的类型，它是指在一个fieldtypemodel XML档案的具体办法由fieldtypemodel.dtd XML数据类型定义。
各种类型，对应一个Java类型和一个SQL类型。
由于分离出不同的fieldtypemodel XML文件，可以使用不同的entitymodel XML与对应的数据库工作
此外，validator可以定义一个扩展的类型为任何字段。
这意味着，当数据输入，validator 可以被执行。
这些validators是定义在类org.ofbiz.base.util.utilvalidate和跟着的定义模式： [boolean isValid(String in);].
# 实体引擎配置指南
# 核心配置指南
# JavaDoc表（文件页面）
# XML文件定义（文件页面）
介绍
OFBIZ 实体引擎提供了一组工具和设计模式来对现实世界中特定的实体（数据对象）进行建模和管理。在本系统的上下文环境中，一个实体就是一个由多个数据域（fields）和该实体与其它实体之间的关系所组成的一个数据对象。这个定义来自于关系型数据库对实体关系模型（Entity-Relation modeling）概念的标准定义。实体引擎的目标是简化企业级应用中对实体数据（对应关系型数据库表）的大量操作，包括定义、维护、通用操作（增、删、改、查实体和实体之间的关系）的开发工作。
实体引擎采用了很多被大多数企业级应用系统公认的位于业务逻辑层和集成层（Business Tier and Integration Tier）的设计模式。许多表示层（Presentation Tier）的设计模式也被引入进OFBIZ，但是仅仅体现在Servlet控制器（the servlet controller）中，没有包括在实体引擎中。在实体引擎中使用的设计模式包括：业务代表（Business Delegate），值对象（Value Object）， 符合实体（Composite Entity(variation)），值对象组装器（Value Object Assembler），服务定位器（Service Locator）和数据访问对象（Data Access Object）。OFBIZ正在计划逐步引入其它设计模式和完善已经引入的设计模式的实现。
Descriptions of these patterns are all available in the book "Core J2EE Patterns" by Alur, Crupi, and Malks, published by Sun. You can also find information on these patterns at the site that contains the early work of the authors before the published book was finished. See http://developer.java.sun.com/developer/restricted/patterns/J2EEPatternsAtAGlance.html. Note that you need a Java Developers Connection account to view this information.
In addition there are a number of patterns used from the upcoming book "EJB Design Patterns" by Floyd Marinescu of TheServerSide.com. These include Data Transfer HashMap and Generic Attribute Access. For unique primary key generation we use an original pattern we like to call the "Ethernet Key Generation" pattern because it uses a collision detection mechanism to insure that multiple servers can use a single database to get banks of unique keys in a database independent way.
实体引擎的一个主要目标是尽可能的提供一种通用的代码结构，来消除在针对每一个实体的事物处理过程中，所有写死（hard code）的代码。这种系统抽象所关注的问题，与那些把数据从数据库中提取出来，并以报表的形式进行输出和显示处理的报表管理或类似系统是不同的，而是类似于每日都可能发生很多事物处理的商业应用系统，实体引擎能大量节省构建类似应用系统的开发费用和戏剧性的减少因为系统存在大量写死的事务处理代码所产生的bug。这种类型的应用系统目前在OFBIZ中实现了一些，如电子商务，入库、出库的帐目管理，任务分配资源管理等等。这些工具能够用来报告和分析系统，但是并不意味着，它能包容千差万别的客户的应用需求，在实际应用中，我们可以基于它来做一些二次开发。
为了达到尽可能少的在系统中出现与针对特定实体操作有关的代码，存储实体属性值的对象结构必须设计成通用的，可以用一个MAP对象来存贮实体的所有域（也可以叫字段或属性），通过实体的名称来区分它们是哪个实体的。根据字段的名称，用一个简单操作String数据的方法，来从值对象中读出或写入某字段的值，并且还可以验证给定名称的字段是否是该值对象的一个合法域。在实体引擎和应用系统之间建立了一个约定（体现实体结构定义文件和字段类型、Java数据类型、SQL字段类型映射关系的定义中），这个约定被定义在特定的 XML文件中，以减少这种灵活性可能存在对系统不利的风险（如数据类型问题可能引起数据库系统崩溃等）。
代替不在系统中书写针对特定实体操作的的代码的方法之一，是把实体的定义放在XML文件中，在系统启动的时候，由实体引擎负责把这些结构定义加载进内存，并且在应用程序和数据源（通常指一个数据库或其它资源）之间建立一些对这些定义的使用规则。在这些XML实体定义中，对实体和属于它们的域，以某种规则和数据库中的表和表的字段建立映射关系。而且实体与实体之间的关系，实体域的数据类型，Java语言的数据类型，SQL 数据类型之间的映射关系，也被定义在XML文件中。
实体之间的关系还可以被命名，以用来区分不同实体组合之间的特定关系。
基于实体引擎这个抽象层，与特定实体操作有关的代码的编写就变的很容易创建和修改。 使用实体引擎所提供的APIs，编写处理实体持久性（增、删、改、查）的代码，可以不同的方式来配置，以便于实现针对实体持久性操作（增、删、改、查）有变化时，可以不改变代码本身，因为它并没有写死。这种抽象的一个典型应用场景就是你既可以通过JDBC直连方式，也可以通过调用运行在EJB服务器上的实体Bean（Entity Beans）的方式或者以其它方式，甚至在系统所提供的框架范围内，使用者运用自己扩充的方式去完成对实体持久性的改变等等。这些不同方式的切换并不需要对代码做任何改动，只需要修改配置文件。
实体建模
实体建模 Files & Locations
最初需要做的是，定义或建模，创建一个新的实体，。在OFBiz 实体引擎这做通过二个XML 文件, 一个为实体模型和另一个是字段类型定义。有链接对XML DTDs 为这些文件在 相关文件 部分上面。原因这两个文件被分离是, 字段类型定义是根据具体数据库定义的。换句话说, 为一个指定的个体模型定义各种各样的字段类型定义也许为不同的数据库存在。当坚持服务器被定义字段类型模型XML 文件被使用为那台服务器被指定。
实体模型XML文件能够在 ofbiz/commonapp/entitydef/中找到。所有实体最初是在 entitymodel.xml 文件中定义的, 但他们现在被分离入各种各样的文件除 entitymodel.xml 文件之外。他们全部命名以以下样式: entitymodel_*.xml
MySQL 字段类型模型XML文件为能够找到在 ofbiz/commonapp/entitydef/fieldtypemysql.xml。有其它数据库具体字段类型文件为Postgres, Hypersonic, Oracle, 和cetera 。从实体模型文件和字段类型文件，数据库能自动地被创造通过checkDataSource在GenericHelper 接口。这可能自动地做在执行或通过工具在WebTools 。
装载种子数据
当表自动生成的时候，数据必须由数据文件加载。这些文件可以是SQL脚本或XML实体引擎文件。 All of the type information and other pre-loaded information such as statuses, enumerations, geo data, etc., are located in XML Entity Engine files in ofbiz/commonapp/db/ .所有的类型信息和其他预加载的信息，如状态， enumerations ，地理数据等，分别位于中的XML实体引擎档案ofbiz / commonapp /分贝/ 。 These files can be located and loaded automatically by the install.jsp page in WebTools.这些文件都可以找到并装上自动由install.jsp一页webtools 。 This page looks in the directories specified in the entityengine.xml file for a given entity group name and finds all .xml and .sql files.这页看起来，在指定的目录下，在entityengine.xml立案某个实体组名称，并认为所有。 XML和。 SQL的档案。 These are listed and confirmation is requested by the page.这些都是上市公司及确认书所要求的网页。
点击Yes，将使这些档案，被加载。
错误信息将会出现在网站页面上，以及对控制台或日志文件。
Data files can also be loaded one at a time by specifying the full path of the .sql or .xml file in the load a single file form.
数据文件也可以装在一个时间通过指定全路径的.SQL的还是.XML文件中加载一个单一文件形式。
而关于这个点，XML实体引擎文件还可以导入和导出通过webtools中的import & export页面 。
一个实体定义的例子
如上所述一个实体就是一个由多个数据域（fields）和该实体与其它实体之间的关系所组成的。在XML实体定义上述每所指明的，除了属性的实体本身，如实体的名称，相应的表名，包名为实体，和元数据实体，如作者，版权公告一个描述，等等。这里是一个XML实体定义的例子：
<entity title="Sample Entity"
copyright="Copyright (c) 2001 John Doe Enterprises"
author="John Doe" version="1.0"
package-name="org.ofbiz.commonapp.sample"
entity-name="SampleEntity"
table-name="SAMPLE_ENTITY">
<field name="primaryKeyFieldOne" col-name="PRIMARY_KEY_FIELD_ONE" type="id-ne"></field>
<field name="primaryKeyFieldTwo" type="id-ne"></field>
<field name="fieldOne" type="long-varchar"></field>
<field name="fieldTwo" type="long-varchar"></field>
<field name="foreignKeyOne" type="id"></field>
<prim-key field="primaryKeyFieldOne" />
<prim-key field="primaryKeyFieldTwo" />
<relation type="one" rel-entity-name="OtherSampleEntity">
<key-map field-name="foreignKeyOne" rel-field-name="primaryKeyOne" />
</relation>
<relation type="one" title="Self" rel-entity-name="SampleEntity">
<key-map field-name="primaryKeyFieldOne" />
<key-map field-name="primaryKeyFieldTwo" />
</relation>
<relation type="many" title="AllOne" rel-entity-name="SampleEntity">
<key-map field-name="primaryKeyFieldOne" />
</relation>
</entity>
这是一个非常简单的实体，仅仅显示了几个点。在顶部的元数据是所有可选的，如果没有指定值将使用缺省的元数据定义整个实体模型文件。包名是用来管理实体，可为任何代码指定一个默认位置将实体的实例化。当一个entity model有许多的实体时，这成为非常有用的。
实体和字段定义
注意：字段primarykeyfieldone指定了一个column名称，其他字段没有指定的。 The col-name and the table-name elements are optional.col-name和table-name元素是可选的。它们可以由entity name或field name，自动生成。这些自动生成极大简化定义实体的操作。
表名和列名都是用下划线区分的，例如SAMPLE_ENTITY 。
实体名和字段名都可以利用Java转换为java类名和字段名，Class变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。实体名对应的Java类名，所以第一个字母是大写，但字段名对应类的一个字段，所以第一个字母是小写。
例如： SampleEntity和fieldOne 对应 SAMPLE_ENTITY和FIELD_ONE 。
复合主键，可以使用多个<prim-key>标签指定字段为主键。
字段类型是指定字段使用的类型，它是指在一个fieldtypemodel XML档案的具体办法由fieldtypemodel.dtd XML数据类型定义。
各种类型，对应一个Java类型和一个SQL类型。
由于分离出不同的fieldtypemodel XML文件，可以使用不同的entitymodel XML与对应的数据库工作
此外，validator可以定义一个扩展的类型为任何字段。
这意味着，当数据输入，validator 可以被执行。
这些validators是定义在类org.ofbiz.base.util.utilvalidate和跟着的定义模式： [boolean isValid(String in);].