A solution:

Static Application Data

Or as I like to call it: SAD kuch

Anyway, the solution to this problem is easy and elegant. At startup, the application initialises a SAD object, which is nothing more then a bean that contains some public static final fields that are filled in when creating the SAD singleton.

Typically you’ll get something like this:

public class SADFactory {
	public final MyCodeObject myCodeObject1;
	public final MyCodeObject myCodeObject2;
	public SADFactory(MyService service) {
		myCodeObject1 = service.findById(1L);
		myCodeObject2 = service.findById(2L);
	}
}

Now we are set! We can use our special static objects anywhere in our application.

Using Spring, you can inject the SADFactory where required (services, managed beans,…). In this fashion the business logic of selecting the right application from the database is contained in a single class.

Way better then using an enum to do the selecting…

Wiith thanks to Yoeri Roels for coming up with this great idea!

Andries

One of the “problems” of doing all the business logic in the Service (or UseCase, Business) Layer is getting the right exception message back onto the screen. Lot’s of times people invent all kinds of home-brewed exceptions: e.g. ResultNotFoundException, InsufficientFundsException, DateTooFarIntoFutureException, …
Another approach, which is far worse, is to let specialized exceptions like a ConstraintViolation (hibernate), UserException (axis) and many others. It couples the front-end to back end.

When defining custom exceptions for every problem, you force the controller to catch all the exceptions that could be thrown separately. Adding a new exception can be cumbersome, and it does not really matter if you define them as checked or unchecked, unless you plan to catch the remaining exceptions with a generic info message like: something went wrong…

What’s the correct solution?

Here comes the BusinessException

public class BusinessException
    extends RuntimeException {
	/** A code indicating the cause of
            the exception. */
	private String code;
	/** The exception that is wrapped by
            the business component. */
	private Exception wrappedException;
	/**
	 * Constructor.
	 *
	 * @param code The code indicating the
         * cause of the exception.
	 * @param wrappedException The exception
         * that is wrapped by the business
         * component.
	 */
	public BusinessException(String code,
          Exception wrappedException) {
		this.code = code;
		this.wrappedException =
                  wrappedException;
	}
	public String getCode() {
		return code;
	}
	public void setCode(String code) {
		this.code = code;
	}
	public Exception getWrappedException() {
		return wrappedException;
	}
	public void setWrappedException(
           Exception wrappedException) {
		this.wrappedException = wrappedException;
	}
}

When a business rule validation has been detected, a new BusinessException should be throw.

When an exception is thrown from any layer beneath the Controller layer, it should be wrapped by the BusinessException.

The code is the key for translation by the view renderer.

Placing this in the architecture

When we place the BusinessException into a widely use architectural stack we come up with something like this:

Advantages

The advantages are clear:

• The controller and other layers are loosely coupled (e.g. no DAO dependency in Controller)
• The transaction can be rolled back, since the exception is thrown.
• The controllers aren’t forced to catch many exceptions.
• No need for those custom made exceptions. One exception to rule them all!

BusinessException versus other exceptions

The businessException should wrap a recoverable violation or exception, that can be displayed in the screen. Transaction is rolled back, and the user can change the input and/or try again.

Normal exceptions are unrecoverable. The transaction is rolled back, and the user is directed to an error page.

It’s not the point to wrap every exception, but only the expected ones. Don’t wrap a It’s a really simple pattern, but a very powerful one.

In essence 4 scenario’s can happen:

1. The first level fails. Typically this is something like a missing required field. The user is redirected to the same page to fix the problem.
2. The second validation fails: a business exception is thrown.  Typically this is a business rule that failed, for instance a balance is too low to complete a purchase. It also could be an exception wrapped by the BusinessException. For instance when the database row has changed after you loaded it.
3. Everything succeeded, the business layer returned normally.
4. The business layer threw an exception (not a BusinessException), the page is redirected to the error page. Unrecoverable, should only be on programming bug.

Conclusion

A lot has to be said for straight and simple win-win patterns. This one is definately one of those.