Look, whos that? Its an object. Object, where do you live?
Theres a serious activity going on theServerSide.com (I seem to be constantly mentioning this resource, pardon me) in regard to persistency mechanisms in the next version of J2EE. Latest trends show that lots of people shift their developments to the lightweight component frameworks like Hibernate. People want to persist POJOs, they usually have no desire to invest into CMP or BMP, or whatever else 3-letter acronym you have in mind, unless such technology is already used in the project they work in, or unless they want to play with it. I find this tendency of lightweight approach very interesting. Still, Im a bit skeptical about OR mapping buzz, because projects I worked in, required a lot of work on the database level, including (oh, no!) stored procedures development and SQL queries tuning (once again, it was before my coming to SAP. Oh good old days! ;)). So, usually I opt for development of custom data mappers (or DAOs, in terms of Core J2EE Patterns), which map domain model into the database and vice versa. This is usually very efficient in all terms, given that your team has no problem with such approach. Of course, ideally, itd require a dedicated DBA person, whod watch how people access a database schema. But, approach which Hibernate takes, and which JDO addresses, is very attractive for the projects that dont require serious database tuning, which dont have insane performance requirements (telecom sector usually has very serious performance expectations and the same is also true for trading applications in the banking sector). People can just take the tool, tell it persist my data and thats it! And people say that some of these OR mappers perform the task really well.
Maaa, look at these cute EJBs!
I dont understand why CMP&BMP came into existence at all. Its a heavyweight and hard to wield technologies. But, this pair already had its bashing session, so I wouldnt repeat what was already said. You can find discussions of this problem all over the web (especially on my favorite resource). Although, Entity Bean zealots are still in the field, so be wary! CMP&BMP in their early days combined remote invocation mechanisms, support for transactions, security, and, of course, persistency. In my point of view, its just a big and heavy burden. Anyway, we learn from experience, and experience doesnt come without mistakes. So, we must be 100% sure that we learn from our mistakes, do not repeat them, and, hopefully, learn from mistakes others make, too. So, what do we have today? Strong reaction from the industry against persistence using CMP or BMP technologies, because its simply a biiig overkill. So, before you decide to develop your next project with either of these two, please, check your requirements at least twice.
Strategy? Who needs a strategy?
You have to be very careful about choosing what kind of persistency strategy to take. Numerous amounts of factors would make their crazy dance, and it wouldnt be simple to make a decision. So, generally speaking, youd have to choose between 3 levels of complexity:
- Simple: JDBC, wrappers around JDBC(like SQLJ)
- Medium: OR mappers, JDO
- High: CMP& BMP
Existence of Open SQL, on top of which you can run any of these 3 approaches, solves one general problem for you of portability between databases. Its a way of doing things, established by SAP quite some time ago. Of course, it gives some certain flexibility to choose database vendor you want, BUT, flexibility doesnt come without a cost. And sometimes this cost can be simply dramatic. Youre unable to use database vendor tricks to optimize your SQL query, like telling Oracle to use this execution plan for the query and not that. And, youre unable to use stored procedures and triggers. I used to move all logic, related to persisting some data, to the database level. But, very often, you cannot do this, because you have requirement to be portable between database vendors, and so, you have to use Open SQL, which has restrictions against doing such kind of things. So, the only thing that can partially save you is batching of SQL statements, so that each statement wouldnt end in a roundtrip to the database.
Schema? What kind of schema?
Existence of a number of technologies doesnt save you from errors in the database schema design. Its a big mistake to claim that every single developer is able to design tables for the problem domain or application (s)hes working in. Its simply wrong. Couple of years ago I thought that I can do database design and write stored procedures and SQL queries. After half a year of work with Oracle DBA in one project side by side I understood that I know nothing about database technology! The guy was doing things with his left hand and closed eyes I was able to understand only after some proper effort. And before that I had a couple of years studying some pretty serious database courses in university! Ok, Java Dictionary and Open SQL abstract you from a big number of problems, but still, a number of basic things must be solved and maintained by a single person per project. So, I would strongly recommend having a dedicated DBA, or at least somebody, whod be responsible for data model, indexes, keys, etc.
So, persistency problem usually crosscuts the whole project. Its reflected in the organization of the project team, in the architecture of the solution, in the design, in the way people write code. Its just something you usually have to think about.
I dont pretend to have covered the whole Java persistency problem domain. Its huge. But I hope, this post would at least provide some ideas on the possible ways of bridging your gap between object and database layers.