Thursday, December 15, 2011

Object Modelling Part 2 - Business Object

In previous post, we have already define the data object to model the record in table. As a further step, we will then build the relationship between object and operation in business object.

Business object is simply the object wrap up the data object and relationship of the data objects. The purpose of having another object to represent the business logic is to have loosely coupled object design.

Consider we have 2 data classes, Transaction and Product which both represent transaction table and product table in database. The relationship of them is defined as Transaction has none or more Product. Operation in between can be seen as Transaction add or remote Product.

So, we define a business object called BoTxn.

class BoTxn{

 private Transaction mTransaction;
 private ArrayList mProductList;
 
 public class BoTxn(String txnID){
   mTransaction = new Transaction(txnID);
   mProcductList = new ArrayList();      
 }

 public void setTransactionTime(DateTime dt){
  Transaction.setDateTime(dt);
 }

 public void addProduct(Product Prd){
   mProductList.add(Prd);
 }

 public void removeProduct(int index){
   mProductList.remove(index);
 }

 public void submitTransaction(){
  //update to database
 }

}
Some sample methods are shown above. We could have another class Customer, for example, to be in the BoTxn. The same relationship and operation could be built for Customer and BoTxn.

The following code shows how to use in the code.
BoTxn txn = new BoTxn(1);
txn.addProduct(new Product(1));
txn.addProduct(new Product(2));
txn.submitTransaction();
On top of the relationship modelling above, I would like to share another modelling in data object in next post.

Monday, December 5, 2011

Object Modelling Part 1 - Data Object

I think object modelling isn't new concept, in fact I learnt it somewhere and added in few ideas that I thought of.

The basic idea of object modelling is that each object represent a row record in a table. All the relationships between tables are mapped in the object so that data in table could be accessed via object without access to data again and again.

To illustrate the concept, consider the following ClassA ( in C#)
class ClassA{

  private String mId;
  private Hashtable _HshTable;

  public ClassA(String Id){
    mId = Id;
  }

  public String property1{
    
    get{
       _getString("property_1");
    }

    set{
       _setString("property_1", value);
    }

  }

  public void refresh(){
    //populate the object with data from DB based on primary key mId to _HshTable;
  }

  public void save(){
    //update everything back to DB based on primary key mId.   
  }

  private _getString(String strProperty){
     if (_HshTable == null) refresh();
     return _HshTable[strProperty];
  }

  private _setString(String strProperty, String strValue){
     if (_HshTable == null) refresh();
     _HshTable[strProperty] = strValue;  
  }
}

The advantages of using object modelling is that we do not need to write code to access the database and join the tables every time if needed. We can access the data via format below.

ClassA ObjA = ClassA("Id01");
String value = ObjA.property1; //get value
ObjA.property1 = "Another value"; //set value

We can access the data in much simpler and structured method.

The next step, we could build operation and relationship to the object. Operation is based on business model. The relationship of the objects also are modelled and we could use it again and again without access the database. It is good idea to separate it to another object, i.e. one object to deal with database and another object to deal with business. From there, we can have a strong base for future extension.

Object Modelling Part 2 - Business Object