Hard Code

The examples so far only deal with single table. But it is very much possible to join multiple tables and still use this mapper. As an example consider three entities as shown below: T_REPOSITORY REPOSITORY_ID int REPOSITORY_NAME varchar CONNECTOR_ID int T_CONNECTOR CONNECTOR_ID int CONNECTOR_NAME varchar URL varchar OWNER_ID int T_OWNER OWNER_ID int OWNER_NAME varchar OWNER_KEY varchar The relationship is clear - a repository has a connector and a connector has a owner. So how can you populate a Repository object containing a Connector Object which in turn has an Owner object. This is just simple. Execute this query. SELECT r.repository_id "repositoryId", r.repository_name "repositoryName", c.connector_id "connector.connectorId", c.connector_name "connector.connectorName", c.url "connector.url", o.owner_id "connector.owner.ownerId", o.owner_name "connector.owner.ownerName&

In my last post, I have shown how the dao support class changed to convert list of maps to list of domain objects. Now the DAO implementation class must also change to use these new methods. Here is the modified DAO class. Listing – UserDaoImpl.java package net.sf.dms.security.dao.impl; import java.util.List; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import net.sf.dms.security.dao.api.UserDao; import net.sf.dms.security.domain.User; import net.sf.spring.dao.AbstractBaseDaoSupport; /** * @author dhrubo * */ public class UserDaoImpl extends AbstractBaseDaoSupport implements UserDao { private Logger logger = LoggerFactory.getLogger(UserDaoImpl.class); @Override public List<User> listUsers() { return (List<User>)this.queryForList("listUsers", User.class); } @Override public void save(User user) { this.insert("saveUser", user.getEmail(), user.getPassword(), user.getFirstName(), user.getLastName()); } @Override public void update(User use

Now a days we make extensive use of Annotations. Whether it is a good or bad practice to mix configuration meta data with code is debatable, but its better than proprietary XML tags. Since we are so used to mixing meta data in our Java code, why not make use of same tactics in building our data mapper. SQL statements in all databases supports something called an alias for column names. I will use this to map a SQL result column to a property in my bean. This is better because even if my column name changes but my alias remains same my bean will be populated properly. I use JODD bean utils. You can download the JODD distribution here .  A problem with JODD is that it is not available in any of the global maven repositories. So you need install the same in your local repository by running the following command  C:\&gt;mvn install:install-file -Dfile=jodd-3.0.9.jar&nbsp; -DgroupId=jodd -DartifactId= jodd -Dversion=3.0.9 -Dpackaging=jar  Use the GUI screens if you are using

I am a big fan of Spring JDBC. The reasons are simple - Full control over SQL. I can optimize, tweak and tune them to my free will. Let me think in terms of those tables and not objects. Cuts down my DAO code significantly. Takes care of all boilerplate code. Integrates well with other parts of my application which mostly uses other Spring components. Simple and easy to setup and get running at high speed Minimal learning curve One area where Spring framework does not do a good job is that of list/finder queries returning n number of records. Lets say you want to find the employees in a certain department. The query is executed and you get a map of records, but then you need to return a list of domain objects to the business tier. You will loop through the map list returned by Spring JDBC, for each of your record create a Javabean populate each field and then add to another list which will be finally returned. So there is lot of boilerplate code here.  Look at the example code b

I am not at all a fan of ORM solutions/frameworks like Hibernate. I have already written and presented my view on different forums and discussions the reasons for my disliking. I truly empathize with Ted Neward that ORM are “Vietnam of Computer Science”. http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx Followup - http://blogs.tedneward.com/2006/06/27/Thoughts+On+Vietnam+Commentary.aspx http://stackoverflow.com/questions/404083/is-orm-still-the-vietnam-of-computer-science Some counter punches http://www.codeproject.com/KB/architecture/ORM_Vietnam.aspx?display=Print I am not convinced as to why should I learn HQL or similar QLs provided by other OR Mapping solutions? Why should I not write and benefit from SQLs which have been proven to be so powerful over the ages and often outlive the lifetime of an application. So many times I have seen SQLs and

Recently I was trying to put together a plugin system for web applications. The idea is similar to Eclipse plugins. Where you bundle your extension in a jar and then drop them in Eclipse-Home/plugins folder, restart Eclipse and you are ready to use it. Note that Eclipse plugins are OSGi plugins. So my initial effort was to see if I could build a pluggable web application with OSGi. After few experiments with Equinox (the Eclipse OSGi engine) and Felix, I moved on to check out Spring DM as well as Spring DM server. But all I all I felt that OSGi / DM involves significant learning curve. The web server bundles are “probably” not of enterprise strength. Still trying to gel with JEE. Significant extra effort required to port applications to OSGi platform. All in all  OSGi / DM has to go few more miles before we build Enterprise server apps using those containers / bundles. But its a very good start and promises a lot in the future. So what to do? I started digging dip into Spring frame