6 days later

I've been in my new job for six days now and thought I'd post my thoughts about what I've done so far. The short answer is "not much". It's actually pretty amazing to me how little is done to prepare for a new person. And I'm not even talking about this specific company, it's a general problem. Even the most glaringly obvious things like getting ids and passwords for databases, version control systems and even permissions on file servers are almost never set up when I go to a new job. Sometimes the environment is responsive to new requests, other times... not so much.

Secondly, when being inserted into a team of people already madly coding away, nobody has the time to give you the lay of the land. So I spent at least a couple days looking a existing code to figure out what I need to do to make my code fit in with everything else. It all seems highly inefficient and a waste of my time and their money. Maybe when you consider just one developer, it may not seem like much but multiply a week of time for every new developer who walks through the door then it's easy to see a pretty big opportunity to save. Do the math with let's say 20 developers and you soon start to think "I could probably build a lot of stuff in 20 weeks".

Anyway, I did manage to build a single web page this past week. But what really impressed me was the number of files I needed to create/edit to enable this one page. I created:

1. a domain object with Hibernate XDoclet annotations
2. a DAO interface
3. a Hibernate DAO implementation
4. a DAO unit test
5. a Service/Facade interface
6. a Service implementation
7. a Service unit test
8. a JSF backing bean and a JSP page.
   

I edited:

1. an application resources properties file (despite the fact localization is not a requirement)
   
2. two Spring XML files
3. a JSF config XML file and
   
4. added some XML to the tiles definition file.
   

Phew! That's fourteen resources and I chose to expose my domain objects to my presentation layer instead of using the DTO pattern which would have increased my resource count by one more! The unfortunate side effect of all this stuff is that I find myself constantly navigating around all these files and fighting the typo-prone XML. I'm starting to question if all this layering and scoffolding is really buying me anything.

In my last job, where I made the decisions about architecture and technologies, I had:

1. XDoclet annotated domain objects (which included named queries)
2. NO DAOs (I felt that the Hibernate abstraction and named queries were a sufficient data access layer)
3. Service Objects (typically singletons with explicitly coded session and transaction management)
4. XDoclet annotated Struts Action/Form objects + JSPs
5. the typical smattering of JUnit test classes.
   

In retrospect it seems so extraordinarily straightforward: One class for my domain layer, Hibernate annotations in the same file for my data access layer, one class for my service layer and typically two classes for my presentation layer and absolutely no XML. When I needed to internationalize my GUI I also had at least one or two resource bundles (*.properties files). But compare 7-8 files against 14 or 15 and you can see that complexity has grown significantly.

Having worked with a variety of people over the years I know there are those who believe that elegance is expressed with simplicity. Look at E=mc² for example. And then there are those who love to wallow in complexity. I love simple, efficient, elegant designs. I'm not sure I've found that here... Not yet anyway. Maybe I'll come to love it over time (my fingers are crossed).

Finally, let me comment on a couple of my statements in earlier posts:

1. There is a simpler way to integrate Spring and JSF so that you can inject Spring configured beans into JSF managed beans. Using Spring's org.springframework.web.jsf.DelegatingVariableResolver configured within your faces config makes it all transparent. Yay! It may not be as good as using only one dependency injection framework but it's a good runner up.
2. Secondly, you can integrate tiles into JSF by configuring org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl in your faces config file.
3. Finally, I read Spring's documentation a little more closely and it appears you can use HibernateTemplate's execute method to call whatever Hibernate code you want. So I can now feel free to use that lovely Hibernate API all I want! ;-)