Java_J2EE_Job_Interview_Companion

code (e.g. Spring) assumes the responsibility of locating and instantiating these servicing components and supplying the relevant references when needed to the client code whereby acting as the factory objects. This external piece of code is often referred to as IoC (specifically known as dependency injection) container or framework.

SpringConfig.xml

<beans>

<bean id="car" class="CarBO" singleton="false" > <constructor-arg>

<ref bean="carDao" /> </constructor-arg>

</bean>

<bean id="carDao” class="CarDAOImpl" singleton="false" />

</beans>

Now your CarBO code changes to: class CarBO {

private CarDAO dao = null;

public CarBO(CarDAO dao) { this.dao = dao;

}

public void getCars(String color) {

//if you need to use a different implementation class say FastCarDAOImpl then need to //make one change only to the SpringConfig.xml file to use a different implementation //class(i.e. class=”FastCarDAOImpl”) rather than having to change all the callers.

List listCars = dao.findCarsByColor(color);

}

}

Your calling code would be (e.g. from a Web client or EJB client ):

ApplicationContext ctx = new FileSystemXmlApplicationContext("SpringConfig.xml");

//lookup “car” in your caller where “carDao” is dependency injected using the constructor. CarBO bo = (CarBO)ctx.getBean("car"); //Spring creates an instance of the CarBO object with

//an instance of CarDAO object as the constructor arg.

String color = red; bo.getCars(color)

You can use IoC containers like Spring framework to inject your business objects and DAOs into your calling classes. Dependencies can be wired by either using annotations or using XML as shown above. Tapestry 4.0 makes use of the Hivemind IoC container for injecting application state objects, pages etc.

IoC or dependency injection containers generally control creation of objects (by calling “new”) and resolve dependencies between objects it manages. Spring framework, Pico containers, Hivemind etc are IoC containers to name a few. IoC containers support eager instantiation, which is quite useful if you want self-starting services that “come up” on their own when the server starts. They also support lazy loading, which is useful when you have many services which may only be sparsely used.

Q 10: What are the different types of dependency injections? FAQ

A 10: There are three types of dependency injections.

Constructor Injection (e.g. Pico container, Spring etc): Injection is done through constructors.

Setter Injection (e.g. Spring): Injection is done through setter methods.

Interface Injection (e.g. Avalon): Injection is done through an interface.

Spring supports both constructor-based injection and setter-based injection. The above example on Q9 is based on the constructor-based injection. Here is the same example using the Spring’s setter-based injection.

SpringConfig.xml

<beans>

<bean id="car" class="CarBO" singleton="false" >

ref bean="carDao" /> </property>

</bean>

<bean id="carDao” class="CarDAOImpl" singleton="false" /> </beans>

Now your CarBO code changes to: class CarBO {

private CarDAO dao = null;

public CarBO() {} ….

public void setDao(CarDAO carDao){ this.dao = carDao;

}

public void getCars(String color) {

//if you need to use a different implementation class say FastCarDAOImpl then need to //make one change only to the SpringConfig.xml file to use a different implementation //class(i.e. class=”FastCarDAOImpl”) rather than having to change all the callers.

List listCars = dao.findCarsByColor(color);

}

}

The above SpringConfig.xml code creates an instance of CarBO object and CarDAO object and calls the setDao(CarDAO carDao) method, passing in the reference to the CarDAO object.

Your caller code would be (e.g. from a Web client or EJB client ) same as above:

ApplicationContext ctx = new FileSystemXmlApplicationContext("SpringConfig.xml");

//lookup “car” in your caller where “carDao” is dependency injected using the setter method. CarBO bo = (CarBO)ctx.getBean("car"); //Spring creates an instance of the CarBO object with

//an instance of CarDAO object and then invokes the //setter method setDao(CarDAO carDao) on CarBO.

String color = red; bo.getCars(color)

Q. Which one to use?

The choice between constructor-based injection and setter-based injection goes back to OO programming question – Should you fill fields in a constructor or setter methods?. There is no clear cut answer for this question. It is a good practice to start with constructor-based injection since it permits immutability (i.e. if your classes are meant to be immutable) and also constructors with parameters give you a clear statement of what is required to create a valid object. If there is more than one way to create a valid object then provide multiple constructors. But if you have a lot of constructor parameters then your constructors can look messy and also if you have many string based parameters then setter-based injection will be more descriptive because each setter name will indicate what the string is supposed to do (e.g. setFirstName(…), setLastName(…) etc)

Q 11: What are the benefits of IoC (aka Dependency Injection)? FAQ

A 11:

Minimizes the amount of code in your application. With IoC containers you do not care about how services are created and how you get references to the ones you need. You can also easily add additional services by adding a new constructor or a setter method with little or no extra configuration.

Makes your application more testable by not requiring any singletons or JNDI lookup mechanisms in your unit test cases. IoC containers make unit testing and switching implementations very easy by manually allowing you to inject your own objects into the object under test.

Loose coupling is promoted with minimal effort and least intrusive mechanism. The factory design pattern is more intrusive because components or services need to be requested explicitly whereas in IoC the dependency is injected into the requesting code. Also some containers promote the design to interfaces not to implementations design concept by encouraging managed objects to implement a well-defined service interface of your own.

IoC containers support eager instantiation and lazy loading of services. Containers also provide support for instantiation of managed objects, cyclical dependencies, life cycle management, and dependency resolution between managed objects etc.

Q 12: What is the difference between a service locator pattern and an inversion of control pattern?

A 12:

Q 13: Why dependency injection is more elegant than a JNDI lookup to decouple client and the service? A 13: Here are a few reasons why a JNDI look up is not elegant:

The client and the service being looked up must agree on a string based name, which is a contract not enforced by the compiler or any deployment-time checks. You will have to wait until runtime to discover any discrepancies in the string based name between the lookup code and the JNDI registry.

The JNDI lookup code is verbose with its own try-catch block, which is repeated across the application.

The retrieved service objects are not type checked at compile-time and could result in a casting error at runtime.

Dependency injection is more elegant because it promotes loose coupling with minimal effort and is the least intrusive mechanism. Dependency is injected into requesting piece of code by the IoC containers like Spring etc. With IoC containers you do not care about how services are created and how you get references to the ones you need. You can also easily add additional services by adding a new constructor or a setter method with little or extra configuration.

Q 14: Explain Object-to-Relational (O/R) mapping?

A 14: There are several ways to persist data and the persistence layer is one of the most important layers in any application development. O/R mapping is a technique of mapping data representation from an object model to a SQL based relational model.

O/R mapping is well suited for read Æ modify Æ write centric applications and not suited for write centric applications (i.e. batch processes with large data sets like 5000 rows or more) where data is seldom read. Although this was generally true of many earlier O/R mapping frameworks, most today (including latest Hibernate) allow for efficient ways of performing large batch style write operations. O/R mapping tools/frameworks allow you to model inheritance (Refer Q101 in Enterprise section), association and composition class relationships. O/R mapping tools work well in 80-90% of cases. Use basic database features like stored procedures, triggers etc, when O/R mapping is not appropriate. Keep in mind that no one size fits all solution. Always validate your architectural design with a vertical slice and test for performance. Some times you have to handcraft your SQL and a good O/R mapping (aka ORM) tool/framework should allow that. O/R mapping tools/frameworks allow your application to be:

•Less verbose (e.g. transparent persistence , Object Oriented query language , transitive persistence etc)

•More portable (i.e. vendor independence due to multi dialect support )

•More maintainable (i.e. transparent persistence, inheritance mapping strategies, automatic dirty checking etc).

Takes care of much of the plumbing like connection establishment, exception handling, configuration etc. You can often leverage the framework’s strategies and capabilities to get efficiencies. Also provides support for eager fetching, lazy loading (i.e. using proxy objects), caching strategies and detached objects (no DTOs required). Hibernate is a popular O/R mapping (aka ORM) framework, which provides above mentioned benefits and features.

Q. What are the benefits of detached objects?

•Detached objects can be passed across layers all the way up to the presentation layer without having to use any DTOs (Data Transfer Objects). You can later on re-attach the detached objects to another session.

Session session1 = sessionFactory.openSession();

you can now pass the “myCar” object all the way upto the presentation tier. It can be modified without any effect to your database table.

When you are ready to persist this change to the database, it can be reattached to another session as shown below:

•When long transactions are required due to user think-time, it is the best practice to break the long transaction up into two or more transactions. You can use detached objects from the first transaction to carry data all the way up to the presentation layer. These detached objects get modified outside a transaction and later on reattached to a new transaction via another session.

Q. How does Hibernate distinguish between transient (i.e. newly instantiated) and detached objects?

• Hibernate uses the “version” property, if there is one.

• If not uses the identifier value. No identifier value means a new object. This does work only for Hibernate managed surrogate keys. Does not work for natural keys and assigned (i.e. not managed by Hibernate) surrogate keys.

• Write your own strategy with Interceptor.isUnsaved().

Q. What is a Hibernate transaction object?

Transaction is a single threaded, short lived object used by the application to specify atomicity. Transaction abstracts your application code from underlying JDBC, JTA or CORBA transactions. At times a session can span several transactions. When long transactions are required due to user think-time, it is the best practice to break the long transaction up into two or more transactions. You can use detached objects from the first transaction to carry data all the way up to the presentation layer. These detached objects get modified outside a transaction and later on re-attached to a new transaction via another session.

Transaction tx = session.beginTransaction(); Employee emp = new Employee(); emp.setName(“Brian”); emp.setSalary(1000.00);

session.save(emp);

tx.commit(); //close session

Q. How do you query the database with Hibernate?

Hibernate provides a very robust querying API that supports query strings, named queries and queries built as aggregate expressions. The most flexible way is using the Hibernate Query Language syntax (HQL), which is easy to understand and is an Object Oriented extension to SQL, which supports inheritance and polymorphism.

Query query = session.createQuery(“Select car from Car as car where car.color = :color”); query.setString(“color”,”black”);

List list = query.list();

Type-safe queries can be handled by the object oriented query by criteria approach.

String color = “black”;

Criteria criteria = session.createCriteria(Car.class); criteria.add(Expression.eq(“color”, color)); Collection col = criteria.list();

You can also use Hibernate’s direct SQL query feature. If none of the above meets your requirements then you can get a plain JDBC connection from a Hibernate session.

Q. How does hibernate support legacy applications?

You can use user defined data types and composite primary keys to get additional flexibility to support legacy applications. It is best practice to use wrapper classes like Boolean, Integer, Long etc instead of primitive types in your persistent classes. For example If you have a legacy application, which has the value of null for a Boolean property in its legacy table, then hibernate will throw a PropertyAccessException if you use the primitive type boolean since it cannot take the null value.

Q. Explain some of the following attributes used in *.hbm.xml mapping file?