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 閱讀(356) 評論(0)  編輯  收藏 所屬分類: 【Torque學習】
          主站蜘蛛池模板: 太康县| 阆中市| 根河市| 股票| 玛纳斯县| 定日县| 南宁市| 朝阳市| 瓦房店市| 中卫市| 西平县| 盐亭县| 车险| 墨玉县| 温州市| 白玉县| 镇康县| 博客| 长武县| 宝鸡市| 巫溪县| 昭平县| 开远市| 太和县| 连南| 长兴县| 苍梧县| 绵竹市| 泉州市| 乌鲁木齐县| 安溪县| 刚察县| 普兰店市| 平罗县| 博客| 交口县| 成武县| 阿图什市| 南阳市| 荔波县| 榕江县|