Thanks for your thoughts. I have a few comments.
>I know this wasn't written to me, but thought I'd offer my thoughts (o: I'm hoping that my discussion will not be a simple howling of a frustrated developer, but a call for someone (a container provider) to address issues which I think are key to EJB's success. >yes, its different to writing client-side code, which is what it sounds >like you are comparing it to. Without wanting to seem rude, >I'm wondering if you've had experience with servlets, or other components >that require a container. I was working on servlets prior >to ejb, so the requirement of a container seemed natural, although I can >see how if one was writing swing apps, then it might seem >very odd. Yes. I have done a fair amount of servlet development, where the servlet code interacts with database through JDBC. In fact, at the moment, I am trying to convert some of this code over to J2EE. Instead of using JDBC, use CMP (to maximize portability and to take advantage of the industry standard). Here is what I see. With servlet and JSP, the interaction of the 'container' and my code is rather simple. I have an array of name-value pairs coming in and an output stream for return. When I debug my servlet code through the debugger, I see a few stack frames that I can't recognize, but rarely do I have to understand what they do. Similarly, with a Swing app, you would see a few stack frames for event dispatching, but you wouldn't care much about its implementation. Not so with EJB/CMP. Much of most important work is happening inside the generated classes. I need to figure out, fine tune, and change what happens when the transient data is written to database. >thats the idea. you said before that you didn't like the idea of debugging >the MFC framework... Well, actually I think you mistook my point. I was stating that the fact that MFC gave me source made it possible for me to use MFC. Otherwise, I would have been hopelessly lost and would not have completed my previous project using MFC. >generated classes to be like the framework - you shouldn't need to worry >about them. essentially, you write the business logic (the >bean class) tell the container what to expose (home and component >interfaces) and the container will plug it all together. Again, the difference is this: MFC worked with me. The source was there. Enough documentation (though some improvement was desired) was available. Even when doc wasn't there, there was code. When necessary, we even overrode parts of MFC to suit our needs. This is not possible with EJB (especially CMP). To summarize, problems I see with EJB (esp CMP) are as follows: - No code. Not enough document. I keep looking through the spec, which reads like some legal document. I'm supposed to look at the spec and jump to the container provider's doc to put them together and make some sense. This is proving to be quite time-consuming and many times unclear. As an example, just look at the confusion around "deferred database update" e-mail thread in this distribution list. - The bulk of really interesting and relevant code is generated during deployment time and not supposed to be seen by the developer. Instead of working with me, the system is telling me "get off my turf". I am not supposed to care how things are persisted. This is either naivete or arrogance. - I'm not supposed to touch (for the most part, I'm not allowed) the generated stuff. If I try to customize or tweak the stuff, I'm now committing a mortal sin. They'll tell you, "you are breaking portability." But, I don't care about portability. I want my application to work. That's all I care for now! - (Though a minor point, it's related to the above) Each deployment cycle in my case is generating many tens of mega bytes of jar and ear files. I haven't figure out the legal way to clean these out. One time, I made a mistake of removing some of these that the system was still using. The result was a mess. I realize I need to update proper XML files, .properties files... Even with all the benefits of EJB, things just shouldn't be this cumbersome, difficult, and cultish. Perhaps, I will learn all these in time and they will become a job security for me, but aren't we simple ignoring developer productivity too much here? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
