Content Comparison

...

...

Business objects are java classes that implement the org.kuali.rice.kns.bo.BusinessObject interface. However, a majority of business objects extend org.kuali.rice.kns.bo.PersistableBusinessObjectBase, which implements org.kuali.rice.kns.bo.PersistableBusinessObject and org.kuali.rice.kns.bo.BusinessObject.

...

Business objects need to implement getter and setters for each field that is mapped between java business objects and the database table (the mapping is described here). Therefore, if, in java, the ACCOUNT_NM DB column is named "accountName", then the getter method should be called getAccountName and the setter should be setAccountName (i.e. like POJO getters and setters). Application uses reflection API and assume that business object fields follows this naming convention so if methods are named different values will not be read or set correctly.

Objects that extend org.kuali.rice.kns.bo.BusinessObjectBase must also implement the toStringMapper method, which returns a map of the BO's fields to be used in toString.

...

Refreshing reference objects mapped in OJB

For references mapped within OJB, the framework automatically takes care of the logic to enable refreshing of a reference. Under certain circumstances, it's able to automatically refresh references upon retrieval of the main BO from the database, and refreshing can also be invoked manually.

...

Refreshing reference objects not mapped in OJB

For references with relationships that are not mapped in OJB, code will need to be written to accommodate refreshing. A common example of this is Person object references, because as noted here, institutions may decide to use another datasource for Identity Management (e.g. LDAP).

...

Creating a data dictionary entry 

Anchor
dataDictionary dataDictionary

Consult this page for more information about how to create a data dictionary file for a business object.

...

A Data Access Object serves as an abstraction layer between the persistence system (e.g. the database) and the business logic layer, which is implemented by services. See the KFS architecture page.

All code specific to the underlying persistence layer (e.g. OJB, JDBC/direct SQL, web service calls, etc.) should be placed in the DAO. The Service layer should contain all of the business logic.

...

• The class is located in the "jdbc" sub-package of the interface because it's an JDBC based implementation of the DAO.

• The class extends PlatformAwareDaoBaseJdbc, which extends org.springframework.jdbc.core.simple.SimpleJdbcDaoSupport, which allows calling SQL statements using the getSimpleJdbcTemplate() method. The "platform aware" component of the name refers to the ability to access a dBPlatform property. This property is of type KualiDBPlatform, which provides methods to support platform specific SQL code.

  Note
  JDBC DAO's are usually better suited towards operations that involve the manipulation of a large amount of data that can be expressed in SQL. JDBC DAO's are not well suited for returning BO's, because there is a lot of logic involved converting a database row into a BO.

...

• The class is located in the "ojb" sub-package of the interface because it's an OJB based implementation of the DAO.
• The class extends PlatformAwareDaoBaseOjb, which extends org.springmodules.orm.ojb.support.PersistenceBrokerDaoSupport, which provides a wrapper to OJB's persistence broker by calling getPersistenceBrokerTemplate(). The "platform aware" component of the name refers to the ability to access a dBPlatform property. This property is of type KualiDBPlatform, which provides methods to support platform specific SQL code.
• Using an Iterator to retrieve results from the database eliminates the need to prefetch all of the accounts in the database into a large list in memory, thus saving time and memory.

...