Pastebin launched a little side project called VERYVIRAL.com, check it out ;-) Want more features on Pastebin? Sign Up, it's FREE!
Guest

Ben Alex

By: a guest on May 6th, 2009  |  syntax: None  |  size: 6.25 KB  |  views: 242  |  expires: Never
download  |  raw  |  embed  |  report abuse  |  print
Text below is selected. Please press Ctrl+C to copy to your clipboard. (⌘+C on Mac)
  1. I wanted to share some details of Spring Roo in light of specifics
  2. raised by Skyway's blog entry.
  3.  
  4. First of all I'd to help readers of the Skyway blog be able to read
  5. about Roo for themselves, download a copy and give it a try. Skyway's
  6. blog didn't include a link, so I will do so here:
  7. http://www.springframework.org/roo and also
  8. http://blog.springsource.com/2009/05/01/roo-part-1/.
  9.  
  10. Moving onto the technical discussion, Roo does not use Eclipse EMF nor
  11. Eclipse technologies. Whilst SpringSource is fortuitous to employ some
  12. significantly talented Eclipse engineers (who lead popular technologies
  13. like SpringSource Tool Suite (STS), Spring IDE and AJDT), we carefully
  14. considered the various engineering issues and elected to build Roo
  15. outside Eclipse. The benefits of this decision include a <3 Mb download
  16. (not a 100+ Mb download!), compatibility with any IDE a person may wish
  17. to use (not just Eclipse), the ability to script the tool, the
  18. significant level of expressive conciseness and productivity possible
  19. through a text-based UI, a very lightweight and flexible add-on model,
  20. plus numerous other benefits.
  21.  
  22. It's interesting that every modern mainstream RAD framework uses
  23. text-based UI paradigms (not IDEs like Eclipse). Of course, Roo has full
  24. Eclipse-based IDE support in the now-free STS product, enabling people
  25. who prefer to stay solely in their IDE to do so and still enjoy a truly
  26. first-class experience. The key point is Roo gives you the flexibility
  27. to use just the IDE, just the text-based UI, or both concurrently.
  28.  
  29. A more important point concerns the issues associated with modern code
  30. generators. I will write an entire blog entry on this topic soon, but in
  31. the meantime will simply observe that existing code generators generally
  32. have some limitations in the way that they operate. For example,
  33. existing code generators emit code in the same compilation units as they
  34. expect a user to maintain, or emit special "do not touch" compilation
  35. units that must be maintained by the code generator indefinitely. Some
  36. code generators prevent the user from editing Java whenever they want
  37. to, or need to specially mark certain members as "edited". Other times
  38. code generators insist on being part of a build script, or require you
  39. to maintain special plugins within your IDE. Some have a questionable
  40. debugging story, limited SCM integration options, lack flexibility for
  41. significantly different architectural models plus facilitate an
  42. explosion of verbose, unnecessary and confusing layers that add little
  43. value. Existing code generators also generally have a limited to
  44. non-existent round-trip story, which is fundamentally critical to
  45. sustainable productivity, and some make it very unclear what is really
  46. going on. We took all of this (and more that I'll blog about) into
  47. account when designing Roo, leading to a non-invasive, flexible and
  48. thoughtful model that uses aspects to ensure we can deliver meaningful
  49. compilation unit simplification whilst resolving the issues present in
  50. modern code generators. Aspect-based approaches underpin most modern
  51. Java technology (including Spring), so it's hardly a big surprise that
  52. Roo would also use aspects given their repeatedly-proven mainstream
  53. usefulness.
  54.  
  55. The layering technique of a separate DAO/repository, services, domain
  56. and controller layer also deserves some reflection. Every modern
  57. mainstream RAD framework places persistence logic within the entity,
  58. which we believe is perfectly sound and pragmatic, especially in this
  59. era when JPA transparent persistence and object graph navigation
  60. undermines most of the initial motivations for dedicated persistence
  61. layers. In relation to services layers, these act as little more than
  62. transaction scripts in most practical usages. These transaction scripts
  63. delegate to so-called domain objects, which themselves are anaemic
  64. DTO-style objects that generally serve little architectural purpose
  65. beyond ORM and MVC form backing usage. This does not represent the
  66. maintainable, encapsulated, efficient OO we all should be striving to
  67. build, and is certainly inconsistent with the definition and motivation
  68. of the patterns purported to being observed.
  69.  
  70. For the sake of clarity, Roo does let you still write services layers.
  71. In fact if you are observing the actual architectural intention of
  72. services layers, they're a very good idea. I wrote a services layer live
  73. on-stage last week at SpringOne using Roo, so it's not particularly
  74. complicated you just create a class as you always have. You can also
  75. write an add-on that emits a separate repository layer if you really
  76. believe you simply you must have one. Naturally Roo separates web
  77. controllers into their own layer by default. Whilst mentioning the web
  78. tier, I'll also note there is no incompatibility with Spring Web Flow.
  79. The Spring project team works closely together and naturally ensure all
  80. projects work well together for the benefit of the community, just as we
  81. always have. Indeed Spring Web Flow functionality is going to be one of
  82. the next add-ons we provide out of the box.
  83.  
  84. Those concerned about layering should also take much comfort from the
  85. fact that Roo automatically delivers its users the
  86. SpringSource-considered best practice for modern enterprise applications
  87. built in the Java programming language. The people designing these best
  88. practices have been using Spring, helping the Spring community,
  89. professionally providing Spring services, speaking at Spring conferences
  90. and leading various Spring projects since as far back as 2003. Every
  91. engineering decision within Roo and the architecture that Roo
  92. advocates is underpinned by this significant history of pragmatism,
  93. community feedback, peer review and engineering integrity. We are
  94. pleased to debate in great depth any engineering decision associated
  95. with Roo.
  96.  
  97. In conclusion Roo brings the best of usability, productivity,
  98. flexibility and quality engineering within reach of enterprise Java
  99. developers everywhere. We solve the numerous problems of traditional
  100. code generation whilst also delivering SpringSource-considered best
  101. practice architecture. Given all of this is freely available in a
  102. lightweight open source project that also includes full IDE integration
  103. with the now-free STS product, we know the community is absolutely going
  104. to love it.