Showing posts with label pojo. Show all posts
Showing posts with label pojo. Show all posts

Tuesday, March 12, 2013

Tied to the Web Layer

Struts 2 claims that "actions can be POJOs". Developers find out pretty quickly that not extending ActionSupport means you lose some Struts 2 functionality (primarily I18N and validation).

One source of confusion is what "POJO" means. POJOs don't mean you don't extend a base class. POJOs are classes not directly tied to unrelated libraries, specifications, etc. For example, Struts 1 actions were directly coupled to the Servlet specification and Struts 1: S1 action methods had signatures including things like HttpServletRequest and ActionForm.

I think of S2 actions as the interface between the client (browser, REST consumer, etc.) and the stuff that actually gets stuff done. S2 handles validation, type conversion, flow (or at least conversion of business-level flow into web-app flow), etc.

Heavy lifting happens outside of anything related to my web layer: persistence, logic, and calculations happen in services, utilities, models, and glue. How is it relevant that my web layer actions are tied to their web layer? What would be the cost of changing web layers?

Web layers all have their own ideas about how to interface to clients. Some use annotations. Some use XML. Some use conventions. They do validations differently. They handle flow differently. They handle form parameters differently. No matter what, the layer between the client and my business logic is going to change, radically or not, if I port to a new web framework.

That my actions extend ActionSupport isn't going to be the pain point: the request handlers are going to change no matter what. How I expose validation errors to the view will change. How I retrieve form parameters will change. How I define validation will change. How I do I18N will change. How I code the view layer itself will change.

That's not to say there aren't (or shouldn't be) unified ways to do all those things, but at the moment, there isn't a single standard approach (and maybe there shouldn't be, although a "web AST" would be cool). The trick is to minimize the coupling between the client and the application's guts.

- Work in progress -