Thursday, May 12, 2011

The Simplicity of Spring MVC 3

The beauty of Spring MVC is the overall simplicity of getting things done. Here is a quick fictional example of the simplicity of a controller in Spring MVC:

@Controller
@RequestMapping("/")
public class WelcomeController {
   ...
}


Above we have the WelcomeController class. All we need to make this class a controller is the @Controller annotation. This controller is mapped to handle all application root requests through the @RequestMapping annotation. Below, we have a few methods that exist within the WelcomeController class that handle GET and POST actions to index.htm.

...
@RequestMapping(value="index.htm", method = RequestMethod.GET)
protected ModelAndView indexGet() { ... }
...


Above we handle the /index.htm GET request and return a Spring ModelAndView object. In the indexGet() method we can add model objects to render in the view and set the view name as shown here:

...
ModelAndView mav = new ModelAndView();
mav.addObject("domainObject", new DomainObject());
mav.setViewName("welcome");
return mav;
...


Below we are handling a POST to /index.htm and here we are expecting our fictional DomainObject class from a form, and we denote that with the @ModelAttribute annotation.

...
@RequestMapping(value="index.htm", method = RequestMethod.POST)
protected ModelAndView indexPost(@ModelAttribute DomainObject instance) { ... }
...


In the indexPost(@ModelAttribute DomainObject instance) method we can handle the DomainObject instance.

...
validate(instance); // do some validation
myService.save(instance); // persist the DomainObject instance
ModelAndView mav = new ModelAndView();
mav.addObject("domainObject", instance);
mav.setViewName("welcome");
return mav;
...


Spring MVC is great for putting together Web applications and the controller infrastructure and configuration is quite fantastic and super simple. A developer can work directly with domain objects in a Web application while avoiding getting wrapped up in technology.

Tuesday, May 10, 2011

Discussing Technical Debt

There are a lot of software developers that discuss Technical Debt. Martin Fowler has a nice post on Technical Debt and I also encountered the term while checking out the Sonar project a little while ago. Technical Debt is something that I feel businesses and developers do not understand in its entirety and for good reasons. When a developer is tasked with making a decision about a functional implementation, options are sometimes available. One implementation can be done by a date d and a possible second implementation can be done by a date d + n. The ideal developer response is to propose all solutions and dates and let the business decide on a path to follow. It is key that the developer provides the pros and cons of all proposed solutions. Most of the time, developers can even eliminate a solution because of governing software development standards or by understanding the pitfalls of a solution which may impede maintenance or functionality in the future. In many cases, developers may not recognize the availability of other options or understand the pitfalls of a solution. In other cases, the business settles on the fastest solution. These scenarios may introduce Technical Debt.

In the enterprise environment, the introduction of Technical Debt may occur quite frequently, that really depends on quite a few environmental factors. So how do we understand and measure Technical Debt? Sonar is definitely a great tool that can help identify code in the red. Technical talent definitely has an incredible impact on Technical Debt. Having high quality developers with experience is very important when identifying and reducing Technical Debt. Managing an inventory or repository of software artifacts that are well documented can provide insight to relevant, proven and performing code. As developers, managers and IT executives we have to recognize and identify where we can alleviate debt by determining how to move forward with the relevant, performing code while leaving behind under-performing or costly code bases.

Technical Debt is not necessarily a platform or language, so moving to Ruby from Java or to Java from C# is not an answer to fix the debt problem. In some cases, changing languages or platforms is like a foreclosure or declaring bankruptcy. You get to put your past behind you, (well kind-of), but if you continue to make poor development decisions you will eventually end up over your head and in the red. Focusing on understanding Technical Debt and putting measures in place to reduce debt is really the way to move forward.