Why use Transfer Objects

Enterprise applications with server side implementation of business logic normally expose some methods for accessing the business components. These methods are call 1…* times by clients to obtain the data that is required by them. These methods, which are normally exposed through remote methods will result in a network overhead.

  • Client applications/portlets normally require data from more than one domain objects or enterprise beans.
  • Client achieves this by making multiple calls to the business components.
  • A lot of chatter over the network degrades network and application performanceperformance.
  • Also the number of read cycles out number the write cycle in majority of applications.
  • On the other hand a enterprise bean may provide more data than needed to a client request.

The solution to this problem is to have a single method call to the server side implementation of the business compoents to extract the required data. This can be done by making a serialized Transfer Object from 1…* domain objects. Transfer Object is constructed on demand by the enterprise bean and returned to the remote client.  

When the client makes a single remote method invocation to the enterprise bean to request the Transfer Object, the enterprise bean then constructs a new Transfer Object instance, copies required values into the object and returns it to the client. The client receives the Transfer Object and uses accessor methods on the Transfer Object to get data from the Transfer Object.

The same transfer object can be used to transfer data back to the business layer in a single remote invocation. 

Example:

TRANSFER OBJECT

public class WorkTO implements java.io.Serializable {
  	public String workID; // can be private. wil have to provide getter
         // setter
  	public String days;
  	public String workdays;
  	public String payLevel; // Transfer Object constructors...
 }

ENTITY

 @Entity
 // for Hibernate Simple POJO
 public class Work {
  Long id;
  private String workID;
  private String days;

  	public WorkTO getWorkTO()
  	{
   		WorkTO to = new WorkTO();
   		to.workID=workID;
   		to.workdays = new WorkDays().getWorkDays();//some other Entity bean implementation
   		to.days=days;
   		to.payLevel = new PayLevel().getPayLevels();
   		return to;
  	}

 }
Advertisements

Reducing Code Dependancy between layers/classes

The concept of programing to an interface or to an abstration is well known and understood. But when it comes to actual implementation lot of mistakes are made. Here I will try to show an example of how “The Dependency Inversion Principle” as suggested by Robert C. Martin.

Basically it helps reduce 3 things i.e. RFI (Rigidity, Fragility, and Immobility) of your code.

Robert C. Martin states that the three defining factors of “bad code” are:

  1. It is hard to change because every change affects too many other parts of the system (Rigidity)
  2. When you make a change, unexpected parts of the system break (Fragility)
  3. It is hard to reuse in another application because it cannot be disentangled from the current application (Immobility)

How do you fix these problems:

1. Any high level or low level component should be dependent on abstraction and not concrete implementations.

2. Abstractions should not depend upon details of your implementation. Interface or an abstraction should cater to the common functionality of your business logic and the lower level modules.

Example:

package example;

public class Account{

    SavingsAccount savingsAccount= new SavingsAccount();

    public void newAccount(Customer customer) {
        SavingsAccount.create(customer);
    }

    class SavingsAccount{
        public void create(Customer customer) {
            //TODO: your implementation 

        }
    }

}

In this example, the Account class is directly dependent on SavingsAccount, which has no abstractions and is the implementing class.

A better way of writing the same code would be:

1. Create an interface Account.

package example;

public interface IAccount{

    public void create(Customer customer) ;

}

2. Implement IAccount:

package example;

public class SavingsAccount implements IAccount{.
public void create(Customer customer) {
            //TODO: your implementation 

        }   
}

3. Implement Account:

package example;

public class Account{

    IAccount account= null;

    public void setAccountType(IAccount account) {
        this.account= account;
    }

    public void newAccount(Customer customer) {
        account.create(customer);
    }

}

As we can see, we have decoupled the invocation from the actual implementation that is your business logic.  Any changes in your acount type class wil not affect the implementation whioch could be a third party.so you are now not breaking the high level code. According to the rules of DIP, this is all we need in order to get rid of RFI in the code.

Css skeleton for your website

I was creating a website and thought that sharing a crude wire frame for building website would be good idea. Here is my effort at that. Feel free to use it distribute it. This is according to the way i wanted it but you can safely change the layout. Could be a good starting point. Remember to create a new style sheet and not keep it embedd in the html itself.

body {
margin: 0;
padding: 0;
background-color: #eeeeee;
}

#container {
margin: 10px auto;
padding: 5px 10px;
width: 960px;
}

/*<– Header –>*/
#header {
position: relative;
width: 100%;
}

#header #logo {
background-image: url(“LOGO_TRANSPARENT.gif”);
background-repeat: no-repeat;
background-position: left;
display: block;
float: left;
padding: 0 5px 0 0;
width: 360px;
height: 115px;
text-indent: -9999px;
height: 115px;
}

#header #connect {
float: right;
padding: 0 5px 0 0;
width: 400px;
height: 50px;
}

#header #connectto {
float: right;
padding: 0 5px 0 0;
width: 400px;
height: 50px;
background-image: url(“LOGO_TRANSPARENT.gif”);
background-repeat: no-repeat;
background-position: right;
}

/*<– content –>*/
#content {
background-image: url(“stripe_b.png”);
background-repeat: repeat;
position: relative;
width: 100%;
height: 500px;
position: relative;
}

#content #featured {
margin: 0px auto;
padding: 5px 10px;
background-color: white;
height: 350px;
width: 500px;
}

#content #left1 {
height: 50px;
width: 100px;
position: absolute;
top: 10px;
left: 20px;
background-color: white;
position: absolute;
}

#content #left2 {
height: 50px;
width: 100px;
position: absolute;
top: 70px;
left: 20px;
background-color: white;
}

#content #left3 {
height: 50px;
width: 100px;
position: absolute;
top: 130px;
left: 20px;
background-color: white;
}

#content #left4 {
height: 50px;
width: 100px;
position: absolute;
top: 190px;
left: 20px;
background-color: white;
}

#content #left5 {
height: 50px;
width: 100px;
position: absolute;
top: 250px;
left: 20px;
background-color: white;
}
#content #left6 {
height: 50px;
width: 100px;
position: absolute;
top: 310px;
left: 20px;
background-color: white;
}
#content #left7 {
height: 50px;
width: 100px;
position: absolute;
top: 370px;
left: 20px;
background-color: white;
}
#content #left8 {
height: 50px;
width: 100px;
position: absolute;
top: 430px;
left: 20px;
background-color: white;
}
#content #left8:hover {
height: 200px;
width: 400px;
}

/*<– other –>*/
#twitter {
background-color: white;
position: fixed;
top: 200px;
right: 0px;
margin-right: 0px;
width: 180px;
}
#twitter:hover{
left: 0px;
}

<div>
<div>
<h1>Company Logo</h1>
<div><img alt=”tw” src=”test.jpg”> <img
 alt=”tw” src=”test.jpg”> <img alt=”tw” src=”test.jpg”></div>
<div>
<p>+001 9837055733</p>
<h6>Address</h6>
</div>
</div>
</div>

<div>
<div>
<div></div>
<div>DcS</div>
<div>DcS</div>
<div>DcS</div>
<div>DcS</div>
<div>DcS</div>
<div>DcS</div>
<div>DcS</div>
<div>Hover effect</div>
</div>
</div>

<div>
<div><h3>Footer goes here</h3></div>
<div><h3>Copyright goes here</h3></div>
</div>

<div>
<h4>twitter widget</h4>
</div>

Why looks matter

What if some one says “you will get all the technology, comfort and refinement of a BMW, but inside the body of a 1998 Fiat Multipla (Rated as the worst looking car) but price remains the same”; would you buy it? At least I would not!

Ok! the point is that, however good or cutting edge your technology might be, you need a good attractive package to sell it. A non-techi customer will naturally be attracted towards a software that has a good UI and good ergonomics. Features obviously matter. A good example of that is the iPhone. There are Nokia, Sony Ericsson, etc. phones in the market which have far better features and operating systems (e.g. multitasking or running multiple programs at one time.) but iPhone is a hot favourite with the fab generation. (New update to iPhone OS will no longer have that drawback.)

So it is important for you to have a good UI design ready for your software application or website along with the features. Good looks sell!!!