This Java architecture is a tough sell

i have given up on EJB long ago. Its simply too complicated and unproductive. Looks good on paper but... I guess Spring and Hibernate are the new kids on the block. My perception is that Spring and Hibernate too is getting a little too complicated. It's Law of Add-Ons and Complexities "If a simple architecture works; invariably it will attract attentions and someone will come along and put more add-ons and complexities over time and will be its demise..."

Ben, Neither Spring nor Hibernate are new kids. Both are very mature products. I can agree with you that both looks complex from first sight, but this is a false impression, at least for Hibernate: 1. You may use it even now (3.x) as good old Hibernate 2.0 with no annotations or any other new stuff. 2. You may use it with Hibernate annotations 3. You may use it with standard JPA annotations (and optionally mix Hibernate annotations when functionality is not covered by JPA) 4. You may use it with EntityManager and your code will be JPA compliant (i.e. no references to Hibernate at all). Note that (3) does not mandate (4) 5. You may add full-text search a top of any option 6. Etc...

So it's absolutely up to you how much Hibernate to use. You may add plain SQL if this is ultimately necessary. You may use DTO along with Entities (this is frequently practical for reporting-like functionality), or with no Entities at all (extreme case, but still possible).

Talking about Spring, for me it is not geeky enough... )))) Seriously, I find a way it's configured too complex. My own preference is Google Guice + Hibernate + Warp Persist. This combo works amazing in our current project: -- it's simple (just read Google Guice and Warp Persist docs -- the documentation is small, but, man -- it's complete!) -- majority of code (business objects, data access layer) is declarative, so it's easier to develop, easier to understand and maintain -- there is only one type of sources, and this is Java sources, so no need for sluggish Eclipse/IntelliJ IDEA plugins to support Spring XML, any descent Java IDE may do refactorings quickly and reliably.

Yakov, do you have any own negative experience with Hibernate? Or you always abandon it as a choice preliminary?

Valery,

You start your comment with a premise that people have to use one of these technologies, and then suggest that it's "up to you how much of Hibernate to use". Why wouldn't you spend some time explaining WHY use any of these technologies at all? Do you see anything wrong with a simple architecture that I've suggested?

Yakov, ok.

Here is 3 major reasons why I'd recommend Hibernate/JPA over plain JDBC for development.

1. You need SQL-to-Object mapping anyway, at least to pass object graph back and force between J2EE server/servlet container and Flex client. You can't pass java.sql.ResultSet over the wire (sure, you can pass XML form of javax.sql.RowSet, but I'm still to see who uses this approach). If you need ORM anyway, then why not use existing mature and proven ORM tool? Ain't rolling your own mapping layer is more time consuming and error-prone?

2. Maintaining/refactoring Hibernate application is simpler than plain JDBC. Majority of data access code (everything besides HQL queries typically) is generated automatically. Less manually written code -- less code to maintain. In case of changes to requirements you may easily and reliably extend/refactor Java object model, instead of fixing numerous hand-written INSERT/UPDATE/DELET SQL statements. And requirements changes happen very frequently during development, typically in form of "clarifications" that seriously affects object model design. Consequences of "agile specification development", you know...

3. Unfortunately, "SQL smarties" is the most rare human resource in application development. So, in case a development team is lucky enough to have at least one on board, then a good tool like Hibernate let him/them maximize productivity. They can do more advanced tasks in shorter term (like designing efficient model and writing efficient queries) while they are free from mundane/dumb work (like writing insert/update/delete for every entity, correctly closing result sets and statements, mapping cryptic SQL exceptions to more usable ones).

Btw, if no one from the team has good SQL knowledge, then nothing will help the project. Neither Hibernate, nor JDBC -- ones who don't know SQL hardly can do any good JPA model or write efficient HQL.

Probably, you assume using Farata's Clear Data Builder in the project, though this is not explicitly mentioned in the post. Then it's the same case as with Hibernate -- you don't suggest using JDBC/SQL directly, you are suggesting instead to use some ORM tool, that automates many of data access tasks. Though, I would say that CDB is more suited for reporting functionality or for CRUD over object model with simple relations -- exactly the case for the project you are describing, as far as I understand... so no objections here :)

Valery, your arguments are poor.

1. No I don't. I'm passing to the client a collection of strongly typed Java DTO that get's serialized and gets automatically recreated as a set of AS3 objects. Why would I need to roll out any mapping layer?

2. JDBC is mandane, but we do use Clear Data Buildr that generates JDBC automatically.

3. I work with people who are not scared of SQL. Moreover, Hibernate will never write you as optimized code as a programmer with a decent knowledge of SQL.

People talk about some teams that don't have people who know SQL. Get rid of these people and hire decent programmers. Thanks to crisis, lots of good people are looking for work.

Yakov,

You are comparing Clear Data Builder vs Hibernate, not a plain JDBC vs Hibernate. This is a big difference, I mentioned this already -- one ORM tool is probably more suitable for a task than another, no doubts here, but plain JDBC is a bad choice.

Regarding (1) -- "No I don't. I'm passing to the client a collection of strongly typed Java DTO that get's serialized and gets automatically recreated as a set of AS3 objects"

Yakov, you have to create that collection of DTO-s from java.sql.ResultSet first, this is what I were called "mapping layer". You can't bypass this step, simply CDB do it good enough.

Regarding (3) -- people who are not scared of SQL are not always SQL gurus, and this scares me. Like if I'm a passenger of a first-day pilot who is not scared about the flight :) And naive tricks of such gurus (like comma-separated multiple values in single column, or dot-encoded hierarchy path in single column, or 50+ columns per table to support 50+ translations) ruined performance of many applications. And they never called themselves dumb, they are definitely smarties, but Relation model is soooo limiting... )))

Yakov, I do not agree with your claim about non-optimized code generated by Hibernate. From my own experience it generates very descend code if designer of object model has a good understanding of 3 things: inheritance vs aggregation; aggregation vs association; lazy vs eager loading. 2 of them are fundamental OOD decisions, so if architect can't make correct decisions of those 2 types, then it's not a Hibernate fault.

Not buying this answer either.

Let me ask an easier question. In which case would you say to a team of programmers, "Guys, you don't need to use Hibernate. Stick to JDBC/SQL"?

Yakov,

You replied in such form, like if I stated that Hibernate is the only ORM tool. No, it's a matter of personal preference, but what I would like to say is that any good ORM tool is better than direct JDBC/SQL coding.

So, "Guys, you don't need to use _any ORM__. Stick to JDBC/SQL" if: 1. You do bulk import/export operations. ORM tools can do this as well, but there is no real benefits of using such tool (and no drawbacks either, though). 2. You do some DB transformations/migrations from one format to another. This is similar to (1), but it's better to use DB specific tools whenever possible -- they are way more simple and a bit more performant, Microsoft DTS coems to mind for ex. 3. You are developing your own ORM )))

Imaging you have a team of strong Java developers and, say an Oracle person with excellent SQL skills. Would you recommend for a Web application a this architecture: a servlet container, JOTM and possibly MOM if need be?

If not, why?

Valery has some good arguments and offered a wonderful contribution to the discussion. It's too bad that you did not respond to her points directly, rather engaging her in a semi-confrontational manner, as she likely would have continued to participate. This would have allowed users like myself who ended up on this page to further benefit from the exchange.