We often design a bean with all the necessary fields (mostly matching to the databases) and thier corresponding getter and setter.
I often confuse where should i place extra methods. like, i don't think so that there should be a method in THE BEAN that load its values from the DATABASE, or there should not be any method which load values from the database and then apply any business logic ... (only one table is involved which is directly mapped to this bean).
What i mostly do is to write 2 classes, one names as TableBean and other called TableBeanLogic which contains TableBean. TableBean class contains all the getter and setter and TableBeanLogic class contains extra functionalities.
I want to ask, Is this design is correct? If not then comment me why not and if yes then please suggest me to improve it more.
The difference between <b>failure</b> and <b>success</b> is often being <b>right</b> and being <b>exactly right</b>.
You are quite correct there should not be logic in the bean to load it from the database. There are several standard patterns for seperating persistance logic and data. I personally like DAOs with DAO Factorys. DAO stands for Data Access Object - this object knows how to load/save/delete your Bean. More over you can make the DAO an interface and have an implementation of it for each DB or other persistance layer you need to support. Then you use a Factory to gain access to the particular DAOs you need.
Your best bet is to learn some patterns - You might start Here. [ September 13, 2006: Message edited by: Tim LeMaster ]