I've apparently really annoyed Frans, and Thomas a little too, so I thought I would do something different. First, let me just say that I've never spoken bad about either EntityBroker or LLBLGenPro that I can recall. In fact, I said publicly many times that both of their products are very good and highly recommended. Why? Because as Frans noted, my WilsonORMapper is "severely crippled" if you need more than simple CRUD. That's right -- my O/R mapper is a simple tool for simple minds only -- and that's all I want it to be. Yes, I want to add cool features, and yes I have a blog to announce it, but I try to also share what I learned in the process. Does that make me arrogant? I hope not, but its not the first time I've been called that, so I'm sorry and I'll try harder, but I hope my accusers can also try a little harder please.
So, before telling you more about EntityBroker and LLBLGenPro, I'd like to share with Frans what I have done right. First, I have done a great job of getting the O/R mapper message out there, as have many others like Steve. If that weren't the case then I wouldn't be getting so much positive email in the last few weeks. In fact, several have went out of there way to tell me how much the hostile attitudes of Frans and Thomas had turned them off! Yes, I have found that there are many people out there that just want a simple O/R mapper, which is where mine excels, but I have also recommended others to EntityBroker and LLBLGenPro while admitting mine wasn't up to their needs. So I think I'm helping the cause in general, and I'm probably even going to increase business for Frans and Thomas to some degree.
Finally, if my WilsonORMapper is so simple, what is it that EntityBroker and LLBLGenPro do that I don't? Both include "real" GUI designers, as will MS ObjectSpaces, whereas my ORHelper merely helps. Both support COM+ transactions, multiple concurrency types (supported now), full data-binding, object query APIs (some support now), cascading persistence (supported now), dirty-field only updates (supported now), and much better support and documentation. EntityBroker supports the major databases already, and I think I just got Thomas to start thinking MySQL seriously too now. LLBLGenPro has plans in the works to support Access, MySQL, and more, so its always been only MS ObjectSpaces (and some others) that I've criticized vocally in that regard. EntityBroker does some really advanced caching, and I have personally used it enough to say I really like it, although it is too "complex" for many simple cases.
I haven't ever used LLBLGenPro personally, since its not really my style, but it looks very good so I do recommend it too. Its designer will automatically discover your relationships, which seems extremely helpful. It also supports stored procedures, as does mine, so again I've never intended to criticize it in this regard. LLBLGenPro also supports things like joins, group bys, validation, and many advanced Oracle features I can only dream about. It also already supports multiple field primary keys, which is something I still need to try to get to. Do I think Frans should use only generic ANSI SQL? No, I've never said that -- I've simply said that starting with generic ANSI SQL will automatically get you working with many databases in the simple cases.
And that's what I don't get -- why are so many O/R vendors totally ignoring the simple users? Are we really going to convince people they need an O/R mapper by raising the bar so high to just get started? I still can't personally understand half of what Frans and Thomas list as their features, and they focus so much on these that the simple ones aren't obvious at all. Many of the other vendors have much better explanations of the benefits of O/R mapping, but most of them do a terrible job at more than code generation. I want people to really understand how O/R mapping can help them, and if they go buy someone else's then that's fine too. But I don't really see how all the antagonistic debates in forums and blog comments make any of these points clear to most users.