Juan Pablo Lorandi wrote: > > > > > I question the assertion that it takes less time to code. > > > > Well, how about this: It takes ME less time to code.
Ok. > > > > > I always code JDBC and EJBs using code generation. > > Code generation; like a wizard? Is it interactive, do you run this on > each build? > In such cases, then it makes no difference, as you DON'T CODE. > No. Code generation, whether using a commercial tool or a home grown tool still takes time. If for no other reason than both must start with a source of some sort. With a commercial tool one needs to know how to use it. With home grown tools there can be a learning time or coding time (as they must be built.) And given that I often do works for hire for different companies that means that each time I need to create the tools over again. I don't use commercial tools because of the several I have tried over the years they often have quirks an biases which make it impossible to configure them. Of course I have gotten faster at creating my own tools. Experience helps. > > Given > > that there is at least one more layer in EJBs that means one > > more layer to be generated. > > I can't follow you here. Do you advocate for not using EJBs at all? I wasn't discussing that. The point was that coding time with EJBs is faster than using JDBC. In my experience using EJBs requires an additional layer. Thus more code. > > > And thus for the techniques I > > use (rolling my own generation > > tools) that means that EJBs always take longer. > > Longer to code? But you don't code... you have your own tools that > autogenerate everything. > On the other hand, I presume it took some time to roll out your > generation tools, and it will take some extra time to maintain them. I > also presume your tools aren't defined by a widely known and adopted > spec, which means that while I can find somebody with EJB experience to > help me, you won't find as many that have "Joe Schell's Generation > Tools" experience. How you account for that is your choice, but the cost > is there, unless you run a one man show. > In my experience each company that I work for uses a different EJB container. And although the specs detail what containers must do they have a tendency not to be specific on how it must be done. Thus for example, neither the EJB spec (2.1) or the J2EE spec (draft 1.4) specifies how one configures a connection pool. Now it is probably just my in-experience but certainly for the containers that I have used, they all used a different method of configuring a connection pool. And the specs, even the newest ones don't specify this. That means that every new container, and perhaps even new version of the same container, that I must learn how to configure the connection pool. So the fact that there are specs don't help a great deal with this sort of thing. > > > > And I can't see that someone manually generating code is > > going to take less time. There are still more layers. > > > > I can code an EJB "manually" using IDEA and XDoclet in minutes. And the > layers, they lend to easier code reuse/location transparency. And you can't do that in JDBC? > Sure, you could manage your own transaction with JDBC and manage the connection > pool yourself; and provided you have a magic button that autogenerates > everything, you'll be as fast. Me, I'm lazy, and don't have the magic > button, so I let the EJB Server programmers do that coding for me. I use > JDBC from within Session Beans so I can relocate code without rewriting > it, and I code based on specs so whenever there's a new developer I > don't have to teach him about the home brewn tools(generation tools, > custom security tools, connection pools, transaction management, session > tracking, etc.). They learn J2EE and from then on they're concerned with > the business logic(to a great extent, nothing is perfect). I wasn't commentting on J2EE but rather EJBs specifically. On the projects that I have worked on there are very few developers that work on the database side anyways. On the projects where I have worked with 30 developers the database layer side was 5 or less developers. So I would never expect to have to teach every developer anything about the database code. Regardless of the the methodology or even language used. That has held with smaller projects where I was the only developer that interacted with the database in any way. > > > > > So I can only guess that you are using a tool that generates > > everything. But if it generates everything for EJBs then > > surely it can generate everything for JDBC? > > Which means the > > coding speed would be the same. > > > > No, my tools do not generate everything for JDBC. Probably any jSQL > compiler may do the trick, but it won't leverage from declarative > security, Security on the EJB? I haven't mentioned that but it seems like a good point. I have never been on a project where security was even a minor concern at the database level. If a user (person or process) has gotten to the database level then they are already validated for all operations. And most projects where security at that level might have an impact it was usually at a field level rather than a entity level. And EJBs have nothing to do field level security correct? > ...automatic transaction enrollment, etc. unless the code is > within a Session Bean. Also database portabilty is a concern for many of > our projects, as they're engines and modules that will be deployed on a > variety of environments. On this last point, there's a tradeoff: EJB > applies some constraints on which those environments will be(some > combinations of DB/App Servers won't be supported), but provides a > cleaner migration path for all of them. Good point. That is harder to do in JDBC because if it isn't compatible then the only way you are going to find out is by testing it anyways. But presumably you do test your code on different databases anyways right? > > > > > Perhaps you are referring really not to EJBs themselves but > > the wrapper functionality that the EJB server provides and > > that one might have to then code when using just JDBC? > > Yes, among other stuff. My point is that benefits/penalties of choosing > EJBs over no-EJBs and Entity Beans over Session Beans + JDBC shouldn't > concern performance alone. Look, here's the bottom line: my customers > money is better spent paying my teams to code business logic and not the > plumbing; I don't want everybody here having to master hardcore Java > concepts such as critical sections, pools, caches, etc. Ideally I want > coders here to solve the business problem at hand. And I certainly don't > want to maintain and support that plumbing as it isn't my core business. > I don't believe I mentioned performance specifically. I am in concurrence with some others post that performance because of the layers is going to be slightly less than using JDBC. But the other point was made, which I also agree with, is that the performance degradation is rather slight and could be safely ignored in comparison to other issues, such a design, which can affect performance significantly. But are you saying that you code business logic in EJBs? > > --A. The > > data set was so small and the requirements of the system so > > low that EJBs would be overkill and even caching of any of > > the data was not needed. > > Cool. Sometimes EJBs are overkill. Nowadays I'm profficient enough to do > it in EJBs faster than not, but I try to make the best judgement on a > case by case basis(not to mention hardware/software associated costs). > If I the user needs a bicycle, he expects to pay a bicycle's price, and > I try to match that while providing the best solution I can give him. > Nevertheless, I don't get small customers anymore, and usually I don't > even use Java for those rare occasions. > I don't believe it applies to small customers. One project that I was familar with involved producing an application for a large international corporation which would be installed in something like 3000 (or 30,000?) places world wide. However the data set that the application dealt with was so small that j2ee and/or ejbs would have been severe overkill. > > > > Now I can certainly imagine data sets that did not follow the > > above. But I find it hard to believe that most data sets > > don't look like the above. > > Some do, in other fields. My experience with banking systems (just > regarding to caches) is that caches are not applicable. There are rarely > record updates, mostly INSERT and SELECT statements. Also all access to > the RDBMS is often serialized. But I've worked on other systems in which > caching was quite useful as the use-patterns are different: > Marketplaces/Auctions, Content(News, Forums), on-line gaming and > gambling (it's much like banks, but many more datasets are quite > cacheable). Of course it applies to some fields. My question is what percentage of fields and of the total developement market is is applicable to? How many developers work for banks as compared to those working for online gambling? =========================================================================== 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".
