＋设为首页 ＋添加到收藏夹
java servlets and javaserver pages (jsp) threaten to collapse out there in the mud houses of server land. developers succumb to the temptation to muddle their pages with complex business logic, and to fill behemoth proprietary libraries with data and subsystem access routines. we find stronger solutions in ejb-based architectures than in fattened jsps, but molding existing sites into ejb-centric designs strikes most of us as a daunting and expensive task.
however, there are clear guidelines for evolving the jsp and custom code approach into a more flexible ejb-based architecture. once convinced that the endeavor is both worthwhile and feasible, developers can take steps to pare down servlets and jsps to simple mvc-compliant presentation layer elements that elegantly access hard-core logic in the form of decoupled and refactored ejbs. this is the practice of growing a jsp site into a full-blown j2ee application.
jsp anti-patterns
in designing software, most of us will agree that mixing presentation logic and business logic is a naughty thing to do. in practice, however, jsps do not naturally lend themselves to a decoupling of these layers, often leading us to compromise our design aesthetics in favor of implementation convenience. after all, were not html designers. we know java, and we dont mind plopping java routines right in the middle of our pages. its quick and dirty. eventually, as the business logic in the pages grows more complex and touches more external subsystems (databases, mail servers, custom proprietary servers), our cool apps coalesce into great balls of mud. figure 1 illustrates such a scenario, in which the client event handlers perform business logic that includes enterprise-level resource usage.its not that a pattern has become obscured in such cases; its that an anti-pattern has emerged. anti-patterns begin as compelling solutions that result in the eventual amplification of the problems they address. in particular, many jsp and servlet sites follow the blob and stovepipe anti-patterns, in which originally compelling code spirals out of control and sprouts numerous tightly coupled subsystems. designers, developers, and engineers step on one anothers toes to turn simple systems into sophisticated ones. the web apps developed in this manner are akin to a house in which cleaning the windows inexplicably causes the roof to leak. the situation grows even uglier when new teams take charge of maintaining the code. justifying the code blob under the "controller" mvc label doesnt resolve the practical problem, even if it sounds promising in high-level architectural discussions.
lengthy procedural code is more... 下一页