JAVA—咖啡馆

——欢迎访问rogerfan的博客,常来《JAVA——咖啡馆》坐坐,喝杯浓香的咖啡,彼此探讨一下JAVA技术,交流工作经验,分享JAVA带来的快乐!本网站部分转载文章,如果有版权问题请与我联系。

BlogJava 首页 新随笔 联系 聚合 管理
  447 Posts :: 145 Stories :: 368 Comments :: 0 Trackbacks

Peers

Everything in Peers resolve around Peer classes. A Peer class has a one-to-one mapping to a Database table. You use each table's associated Peer class to do operations on that table. Peer classes are generated for you automatically.

Peer classes have static methods only, so you would never create objects of Peer classes. It is not necessary to have objects on this level because of the one-to-one mapping with a table. Peer methods are thread safe.

Peer classes are generated for you automatically. For each table, two Peer classes are generated: Base<table-name>Peer and <table-name>Peer. The Base<table-name>Peer class contains all the functionality and should not be changed. The other class is empty but can be extended to add or change functionality. If you regenerate with torque only the Base* class changes. This allows you to change the schema, but still keep your existing code.

Data Objects

A Data Object holds information about a single row of a specific table. Data Objects can be generated automatically for you. It takes the form of Bean properties for each field of the table.

The Data Object classes also generated automatically. For each table, two Data Object classes are generated: Base<table-name> and <table-name>. As with the Peers, the Base<table-name> class contains all the functionality and should not be changed. The other class is empty but can be extended to add or change functionality. If you regenerate the classes, only the Base* classes will be overwritten.

Data Objects are used almost exclusively with their related Peer classes. Where peer classes "wrap around" around a database table, a Data Object "wrap around" individual rows of the table. The two always go together.

You normally use Data Objects in one of two ways. The most common way is to extract data after you called a doSelect on a Peer class. The doSelect method returns a List of Data Objects that holds the data of the resultset. Secondly you can create Data Objects and call their save methods to insert or update the related row into the database.

Criteria

Criteria is an abstraction of the criteria of an sql query. We use criteria objects to specify the criteria of a sql statement. The database adaptor classes contains information on how this Criteria object will be translated to different flavours of sql.

Criteria is in effect a map of field names and values that forms the criteria of a query. By default the comparison is equals (=) but you can define any comparison operator (<, >, <=, > =, IN, etc.).

Criteria can also be used to do some other sql function like ORDER BY or DISTINCT. If Criteria is too limited for your purposes (which should not happen often) you are still free to use raw sql queries.

Database Maps

The Peers make use of a DatabaseMap class that holds internal data about the relational schema. You will seldom, if ever, need to work with the DatabaseMap class. It is used internally by Peers to discover information about the database at runtime.

There is exactly one DatabaseMap for each relational database that you connect to. You may wish to connect to more than one database in your application. You should then have one DatabaseMap for each of the databases.

DatabaseMaps are constructed by classes called MapBuilders. Torque generates MapBuilder classes for each of the tables in your schema. The MapBuilder for a table is called when the Peer class for the table is loaded.

All DatabaseMaps are instances of the class org.apache.torque.map.DatabaseMap. They are kept in the instance variable TorqueInstance.dbMaps. The Map for the database with the name key can be retrieved by the method Torque.getDatabaseMap(key).

ID Broker

The ID Broker is used to automatically create unique primary keys for tables. It creates id's from a database table called id_table.

Of course Torque also supports using the ID generation provided by the underlying database system - just set the idMethod attributes as desired in your schema.

The ID Broker is used in the underlying Peer code. After you have generated your object model classes you need not worry about it anymore.

Database adaptors

Although all databases supported by Torque understand SQL, there are differences in the behaviour of the databases which the Torque runtime needs to know about. For example, the standard (String) format of a date object in an Oracle9i database is different from a postgresql database. The adapter for a database provides the necessary methods to hide such differences from the user. For example, the adapter provides a method to create a String in the database's preferred format from a Date object.

Adapters are subclasses of the org.apache.torque.adapter.DB class. The adapters are stored in the private map TorqueInstance.apdapterMap; the key of the map is the name of the database (e.g. "bookstore"), and the value of the map is the adapter. The adapter for a given key can be retrieved via the method Torque.getDB(key).

If your database is not yet supported, you can read the Support for new Databases docs on how to create a new adapter for your database.

DataSourceFactories

To access a database, a connection must be made to the database. A DataSource is an object which can provide Connections to the database. A DataSourceFactory is used to configure and provide one DataSource.

All DataSourceFactories used by Torque must implement the interface org.apache.torque.dsfactory.DataSourceFactory. The DataSourceFactories are stored in the private map TorqueInstance.dsFactoryMap; the key of the map is the name of the database (e.g. "bookstore"), and the value of the map is the DataSourceFactory. The DataSourceFactory for a given key can not be retrieved by a public method; however, a connection from the DataSource for the DataSourceFactory for a given key can be obtained by Torque.getConnection(key);

 

Peers

Peers中的一切都转换到了Peer类中。一个Peer类和一个数据表对应。你可以使用和某个数据表相对应的Peer类来操作这个表。Peer类都是自动生成的。

Peer类只含有静态方法,所以不必创建任何Peer类对象。由于和表的关系是一一对应的,所以在这个层次上没有必要创建对象。

Peer类都是自动生成的。每个表生成2Peer类:“Base表名Peer”类和“表名Peer”类。“Base表名Peer”类包含了所有功能,并且不应该进行任何改动;“表名Peer”类是“Base表名Peer”类的子类,初始时是空的,可以添加或者更改方法以提供需要的功能。如果使用Torque重新生成Peer类,只有“Base表名Peer”类中的代码发生改变,已有的存在于“表名Peer”类中的代码仍然可以使用。

 

 Data Objects

一个数据对象保存了一个表中的一行数据。数据对象是自动生成的。它以Bean属性的形式保存了表中的每个字段。

数据对象类也是自动生成的。每个表对应生成2个数据对象类:“Base<table-name>”和“<table-name>”。功能和使用方法与Peer类相似。

数据对象是由和其相关联的Peer类以几乎独占的方式使用的。Peer类把表包装了起来,而数据对象把表中的单行数据包装了起来。二者往往联合使用。

数据对象有2种使用方式。最常用的方式是在调用一个Peer类的doSelect方法之后使用数据对象抽取数据。doSelect方法返回一个含有数据对象的List,其中包含了查询结果集(Resultset)中的数据。第二种方式是创建数据对象,然后调用该对象的save方法来把相关的行插入或者更新到数据库中。

Criteria

Criteria是对一个sql查询条件的抽象。我们使用criteria对象来指定一个sql语句的查询条件。数据库调节器类(adaptor classes)包含了如何转换criteria对象以便适应不同的数据库的信息。

Criteria从作用上来说是构成一个查询条件的字段名称和值的映射。默认的运算符是“=”,但是也可以自己定义运算符(<, >, <=, > =, IN, etc.)

Creteria也能用来做其它的查询,如ORDER BY 或者 DISTINCT。如果Criteria不能满足你的要求的话(这种情况不应经常发生),你仍旧可以使用原始的sql语句进行查询。

ID Broker

ID Broker用来自动创建表的主键。它根据一个叫做id_table的表创建id

当然,Torque也支持使用当前数据库生成的主键 只要把idMethod属性设为schema中想要的值就可以了。

ID Broker被当前的Peer代码使用。在你已经生成了你的对象模型类之后,你无须再考虑它了。

posted on 2008-05-22 11:31 rogerfan 阅读(336) 评论(0)  编辑  收藏 所属分类: 【Torque学习】

只有注册用户登录后才能发表评论。


网站导航: