| |
1:08:43 PM |
 |
... and my comeback to Mike's comeback to Joe ...
Agreed - a persistence layer is essential for any large project. Once you know how to use your framework properly, you'll use it for small projects too. I can get the EE up and running for new projects in literally minutes - including building the whole entity model. Do that with JDO 
The only thing extra I have to add to my projects is add a <jdo srcdir="src" destdir="classes"/> ant task and @jdo JavaDoc comments to the classes I need persisted (custom built with QDox - plug plug!) - and that's it. That task will scan my source dir for classes marked as persistent - generated the mapping files (which I never look at) into a tmp directory, tell Kodo to enhance the class bytecode and connect to my db and update the schema. Lots of stuff going on under the hood, but all I have to do is add one ant taskdef and include a Jar.
I find that the performance of OR frameworks is generally pretty poor. The problem with 'use objects and let the framework handle persistence' is that you really do need to know how the framework works to work out the performance of your code. Same deal with RMI. You can't really just forget the object is remote, or your code will be hellishly slow.
I agree with that. You still need to be aware of it's persitence but (mostly) it shouldn't cause extra code to be written. It's like knowing when to use and ArrayList and when to use a LinkedList.
Joe then defines JDO....
I wish JDO defined this much :). Kodo offers much more than the raw JDO spec - most other JDO implementations are a bit sucky :(
Classes define all. Definitions of data schemas should come from the java classes themselves, not config files or existing databases.
I don't agree. I love the ability to edit the entitymodel.xml file and add new entities in a flash. It's wickedly fast, and OFBiz goes and creates the tables and columns for me. Granted by your definition OFBiz isn't an OR framework as it doesn't map objects directly.
OfBiz does make this pretty easy.
The reason I like classes is because you have the power of strongly typed objects. If you want to change your model it makes it pretty easy to do with IDE based refactoring tools. It's hard to do this with strongly typed objects. It also allows objects to have behavior associated with them and data to be neatly encapsulated.
Granted it is easier to write the classes in pure XML but defining a simple class isn't that much work and the advantages above are well worth it.
Transparent database management. The tool should be able to look at your object model and find out what changes need to be done to the database schema to support it (and optionally make the changes).
This is a must, and something that very few frameworks do at all.
Aye. Thankfully Commons-SQL is trying to remedy this by providing a reusable set of database management tools (such as schema generation/migration) which can be used in conjunction with other O/R tools.
Hibernate, Object Relational Bridge, Castor, and OfBiz are all awesome opensource products. I'm not knocking them! :)
| 