Code Generation with giant CRUD
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Code Generation with giant CRUD

  • 4,258 views
Uploaded on

The presentation I gave at JavaPolis 2007 about code generation for big domain models.

The presentation I gave at JavaPolis 2007 about code generation for big domain models.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,258
On Slideshare
4,126
From Embeds
132
Number of Embeds
6

Actions

Shares
Downloads
50
Comments
0
Likes
1

Embeds 132

http://www.tomklaasen.net 111
http://tomklaasen.net 11
http://www.slideshare.net 4
http://www.slideee.com 3
http://www.linkedin.com 2
http://www.slashdocs.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Code generation with giant CRUD Tom Klaasen 10to1
  • 2. Tom Klaasen Works professionally with Java since 1999  Co-founder of 10to1 (http://www.10to1.be)  Has worked on a project involving a lot of  code generation over the last 2 years tom@10to1.be  www.javapolis.com
  • 3. Overall Presentation Goal Reducing typing with code generation www.javapolis.com
  • 4. The question Who wants to type in 1000+ Java class files? www.javapolis.com
  • 5. The problem Mission: “Create generic CRUD screens for  a domain model” www.javapolis.com 6
  • 6. The problem “Our domain model will likely contain a few  hundred classes” www.javapolis.com 7
  • 7. The problem “Oh, and we’re not sure which parts will  stay generic and which won’t” www.javapolis.com 8
  • 8. The problem “And please, have it done in 3 months, with  4 developers” www.javapolis.com 9
  • 9. The problem “And use RUP. But don’t wait for the  analysts to finish their job, because we don’t have that kind of time” Change your code when the Use Cases are  finished www.javapolis.com 10
  • 10. The problem “(And don’t wait for the data modellers  either. We really don’t have any time.)” www.javapolis.com 11
  • 11. The problem Domain model with 500+ classes  Each class: 1 interface, 2 implementations  Relations between those objects are first-  class citizens Also 1 interface, 2 implementations  Some classes have a lot of performance-  gaining methods Fine-grained getters and setters for the relations  Each class has 10+ attributes  Each needing a getter and a setter  www.javapolis.com
  • 12. The problem For each domain class:  DAO  Manager  FormAction  form.jsp  searchform.jsp  list.jsp  editflow.xml  Another 1000 lines of Java, JSP and XML  code www.javapolis.com 13
  • 13. The problem Result: 2000+ lines of code per domain  object For 4000 domain objects  Who wants to type these in?  www.javapolis.com 14
  • 14. The problem Most of the constructs will change over  time 4000 x 2000 lines of code are subject to change  Who wants to make these corrections?  www.javapolis.com 15
  • 15. Other constraints 2 years ago: beginning of 2005  Java 1.4  www.javapolis.com 16
  • 16. The approach Generate everything  But: make it possible to hand-code  everything Attribute definitions: in the DB  www.javapolis.com 17
  • 17. Generation process: first generation .hbm.xml DB Tables .jsp FormAction Domain DB .java Flow.xml Manager DAO www.javapolis.com 18
  • 18. The tools AppFuse + AppGen  Ant  XDoclet  Hibernate  Home-written Access tool  www.javapolis.com 19
  • 19. The tools XDoclet: extended with custom annotations  @gui hidden=”false”  @relation mandatory=”true”  www.javapolis.com 20
  • 20. Disadvantages Ant: messed-up build scripts  XDoclet  2 ‘design decisions’ for each information to be  passed slow  www.javapolis.com 21
  • 21. Improvements Maven  Clean project structure  FreeMarker  More flexible than XDoclet  Read directly from the DB  Don’t always generate everything  More and more hand-coded ‘generic’ files  As knowledge about the domain grew  www.javapolis.com 22
  • 22. The end situation .hbm.xml DB Tables Domain DB .java .jsp www.javapolis.com 18 23
  • 23. The pros Always flexible  When no knowledge available: generate  everything Override with hand-coded parts where necessary  When patterns and securities arise: hand-code  them in a generic way www.javapolis.com 24
  • 24. Comparison with other solutions Hand-code everything (and every change)  Hire a lot of code monkeys  Design everything generically, correctly the  first time And good luck with that  Trails  Code is not generated  Thus impossible to override  Rails (with JRuby)  This started in 2005, remember?  www.javapolis.com 25
  • 25. Conclusion Code generation can make you flexible and responsive. Do try this at home. (Or at work) www.javapolis.com
  • 26. Q&A View JavaPolis talks @ www.parleys.com
  • 27. Thank you for your attention