First of all, thanks for your input.

I’ve used this approach in several projects. Well, indeed it was almost the same database structure with different metadata configuration, so it was able to hold different entity types in each project (without any changes in the DAO layer code!).

In a near future (hopefully!) I intend to complete this article with a third part to explore this a bit more, but the main idea is that, once relationships are defined on runtime or by means of metadata configuration, it should be possible to do the same with any other kind of data, so many different types of logical entities could be stored in a single physical structure (a set of database tables). Again, performance takes a hit, but there are advantages that, in my opinion, outweight this for many kinds of applications.

Unfortunately these projects are not open source, so as of now I can not publish the code or any specific details, only the general philosophy behind them.

From our point of view, this method can save us an amazing amount of time. Previously, lets say we wanted to add a new type of object: “Monkeys” to “Companies”, it would have taken quite a few hours to program the model, view, controller, actions, struts config, and database. Now all I need to do is define the object in the database, and everything is generated.

This is great for us as we always get little customizations which require adding a new object type, or varying an object, which is incredible easy now.

I would be interested to know if there are any other projects actually using this method? Especially open source ones.

Great article.

It’s been a while and stuff happened. Here is what I heard about. In CouchDB-land that is. Enjoy!

In Production!

Wego, a travel meta-search engine in beta uses CouchDB. No mention of how and what for exactly, but seeing people going live with C…

hubs about Object-Oriented Databases to Object-Oriented databases are an interesting concept. Forget about database schemas and ORM mappings, and design your own domain model as you want. Then simply store it all, just like if it was kept in memory, bu…

I think with the rise of Java 5+/JEE 5 there is less and less a need for spring. I like the simplicity of Guice, and while DI is just another way of doing something developers have always done, it does have its drawbacks which i think you have accurately captured.

Here is a comment i left on Kevin’s (Guice co-creator) blog which talks along the same lines, and why i don’t mind the Guice way!

http://smallwig.blogspot.com/2007/06/coupling.html#c347596939873173442

The main advantage, is it’s integration with different technologies and frameworks out there, and it’s AOP oriented configuration which makes it very powerful.

K

By the way, there is a third option for the SessionFactory problem. ServiceLocators don’t need to be accessed statically. So if you have two objects that require different Factories, you can pass different instances of the ServiceLocator to each object, each of which has a different instance for a given interface. Yes, that’s DI, so what? I just need to pass one object. I’ve never said that DI is bad, just that sometimes SL may be simpler. And the mix of both can be pretty good, too;D

Everything looks ugly in the corner cases. That’s why they’re corner cases, isn’t it?

Bean + one dependency on some DAO somewhere in the app context. Write a simple test class that spins up the Spring app context like you want and you can verify before you do anything else that the bad label problem doesn’t appear.