I am a bit biased on this being the original architect of the OFBiz framework, and having done quite a bit of the implementation as well.
That said... On Dec 19, 2007, at 12:20 PM, Sonny To wrote:
Hi, I'm evaluating an ecommerce solution for a client. I installed ofbiz and the demo looks great. It has all the feature that my client needs. Then I asked myself what if I needed to customize and modify the code... so I looked at the code. I realize ofbiz was started a few years ago and developers had to build a lot of infrastructure to do stuff like persistence... something I take for granted today with hibernate. If you can start over again, what would you change? I would replace the whole entitymodel.xml stuff with a rich domain model. I'm new to ofbiz so correct me if I'm wrong. It seems entitymodel.xml is used to define domain objects. Why not define domain objects in Java?
The main reason not to is that a Java object model is object oriented, not relational like the relational (SQL) databases that OFBiz uses for persistence. Because these are very different things a great deal of mapping is needed to translate from a relational model to an object model, hence the term object-relational mapping.
The OFBiz framework avoids this by using a relational data model top to bottom.
Java is has a much richer type system than xml. Furthermore entitymodel.xml its redundant because u will need a Java version of the entity defined in the xml anyway.
You're right, if you want an object model you have to do mapping code between the object model and the relational model. That's why we don't do it (we don't want the overhead!).
If I could do it over, I would remove the entitymodel.xml and the org.ofbiz.entity.* packages and replace it with hibernate.
I wouldn't... Hibernate IS an object-relational mapping tool. It's a great one, but the redundancy is still there. That would add tens of thousands of lines of Java code to OFBiz, and at the end of the day it probably wouldn't reduce more than a line here and there of the existing code base... but there's more, so much more!
If we used an object model on the data tier we would have to do object- service mapping, object-form mapping, object-etc mapping... and that would introduce so much redundancy that trying to build an ERP system based on it might kill our poor little community! (well, it's fairly big, but still tiny compared to the typical ERP implementation teams plus large scale ecommerce teams, etc, etc that involved many hundreds, or many thousands even, of full-time people).
Browsing the code, I do not have a good sense of what the domain objects are. The domain objects are one of the important pieces if not the most important part of any system. Take a domain concept like Product for example. I see there's a org.ofbiz.product.* packages but no Product class! or is it hidden somewhere in an entitymodel.xml file? ofbiz does not have a good domain model IMHO. Because of this adding new feature and maintenance would be costly IMHO. I'm hesitant to recommend to the client because of the potential high maintenance even though it has all the feature my client needs.
By "domain model" do you mean object model? OFBiz has two main models actually: a data (entity) model, and a service (login) model. This is more real-world friendly than an artificial "domain model".
If I were to start over again, I would use Grails which is a Groovy/Java framework using Spring, Hibernate, and SiteMesh. Grails copies ideas from Ruby on Rails. With Grails/Ralis, I can create a solution that meets the clients need in a month or two.
Have you compared the efficiency of such an architecture with the efficiency of the OFBiz framework?
Like I said above, it would overwhelm the community for both the creation and maintenance using that approach. Why do you think such a project doesn't already exist?
So if you had to do it over again, how would u do it?
There are a lot of things I'd to clean up in the framework, lots of things that we've learned over the years and we've added better ways to do things and then had to deprecate old things and such. From a high level perspective, like a general pattern and architecture approach? Nope, I wouldn't change a thing.
But, then again, I am biased... I've heard the same sentiments from a lot of OFBiz users, but we don't have the marketing budget or big corporate affiliations to convince the world en-masse... it's just happening one developer at a time.
-David
smime.p7s
Description: S/MIME cryptographic signature
