WORK IN PROGRESS : Help us with your contributions!!
Framework architecture overview


The SmartWeb persistence tier is represented by the net.smartlab.web.DataAccessObject interface which specifies the SmartWeb variant of the CRUD operations: findByKey, remove, update and list.

This is the basic interface we suggest to implement whenever you wish to create a persistence tier for an unsupported resource tier, but if your intention is to store your datas into a relational database your life is going to get easy as we already provide such implementation through the BusinessObjectFactory abstract class

Business Object Factories

The standard persistence implementation versus a relational database is represented by the BusinessObjectFactory base class which have the function to supply Hibernate persistance for business object implementations. To be able to build a factory class, you should inherit from the net.smartlab.web.BusinessObjectFactory abstract class provided by the framework.

This class, in addition to other methods, implements the DataAccessObject interface methods:

  • Collection list (SearchInfo info) retrieves all instances of a specific persistent class adhering to a set of criteria;
  • Collection page (SearchInfo info) works like the list method but returns a paginated collection (a collection navigable per pages), also known as Paginator;
  • Object findByKey (Serializable key) retrieves a unique item using the persistent class identifing key as criteria;
  • void update (Object object) updates the persistent representation with the current object values;
  • void remove (Object object) permanently deletes a persistent instance.

The SearchInfo parameter establishes the criterion with which the search must happen. If the parameter turns out to be null the objects without filter will come all returned. Consider the SearchInfo instance as a utility tool to avoid defining a set of methods on BusinessObjectFactory to accomplish simple searches differentiated only by the filtering criterias or ordering. This class doesn't replace Hibernate Criteria or Query classes as it doesn't provide the same functionalities, features or customizabilities, it's usefull only for simple search criteris definition.

The page method resolves the problem to have paged objects as it return a special collection having a special iterator implementation: whenever you iterate over the collection you are really iterating only the current page. Naturally you can set the elements per page, the page you want to iterate and you can always get the total amount of selected items and the number of pages available.

All the enlisted methods throw a DAOException representing a generic exception occurred while performing the operation on the resource tier.

Getting started with BusinessObjectFactory

The SmartWeb framework API guides you to realize a BusinessObjectFactory implementation for each of your BusinessObjects, consequently, if you have a BankAccount business object you should have a BankAccountFactory chich implementation is in most cases very simple:

public class BankAccountFactory extends BusinessObjectFactory {

        public Class getMappedClass() {
                return BankAccount.class;

Mapping persistence class with hibernate and xdoclet

All the persistence tier details (like which attributes need to be stored and in which table, column or type) can be easily specified using XDoclet directives on top of your business object implementations:

public class BankAccount extends BusinessObject {

        private long id;
        private String owner;
        private double balance;
         * generator-class="native"
        public long getId() {...}
        public void setId(long id) {...}
         * column="owner" type="string" lenght="100"
        public String getOwner() {...}
        public void setOwner(String owner) {...}
         * column="balance"
        public double getBalance() {...}
        public void setBalance(double balance) {...}
         * @hibernate.version
        public double getVersion() { return super.getVersion(); }

The SmartWeb framework suggest you to adopt the optimistical locking approach to cuncurrent modifications, but other approaches (including the pessimistical locking) are allowed. If you agree with the optimistical locking suggestion you should just reimplement the getVersion() method as in the previous example and add that information whenever you read/write the object versus the presentation tier.