Opinion: Java with Spring just as productive as a 4GL RAD tool

Discussions

News: Opinion: Java with Spring just as productive as a 4GL RAD tool

  1. Erwin Bolwidt and Vincent Partington did very well in a rapid application development competition which pitted their open source J2EE toolset, centered on Spring, against 4GL tools, among others. They've documented their toolkit as well as "what went well and what went wrong," with an assertion that Java with Spring is just as productive as a 4GL RAD tool.

    Their toolkit was something familiar to many: Spring, Hibernate, Tomcat, MySQL, and Eclipse (with the Eclipse Web Tools Platform plugin, and the Hibernate synchronizer plugin noted as well.)

    One of their main points is about the non-invasiveness of the toolset, saying "Neither the IDE nor the libraries rigidly forced us in a direction thereby making it easier to combine them."

    Strong Points
    We believe these to be the strong points that benefited us most:
    • Easy team development because of component separation
    • Fast and powerful assembly of our own code and third party components (such as Hibernate, Axis, etc.) into the application using the Spring Framework
    • Easy fit of third party libraries into the application
    • Having a skeleton application (based on the Spring PetClinic sample), including a consistent skeleton GUI, available to bootstrap the project from
    High marks were given to the tools, as well.

    Obstacles
    The biggest problem was the speed at which we could build the user interface. Despite having a skeleton GUI and customized JSP tag files, this took us significantly more time than other teams that worked as fast as we did. Time that could have been spent on completing more parts of the assignment and on better peer review of the code. A faster solution for this problem would have given us the edge, and victory. But alas, we didn't have or know a good solution that fits into the toolset that we are using.
    The layered nature of the J2EE deployment model was also mentioned as a problem.

    Conclusion
    Java can be really productive right now. It can equal the productivity of 4GL tools that are specifically designed for rapid application development and outpace .NET which is regularly touted as being more productive than J2EE.
    The conclusion of the two authors was that a faster development cycle for the user interface would have possibly enabled them to win the competition (they placed third).

    There are a lot of questions raised by the paper. Some are:
    • Are 4GLs actually productive, such that a positive comparison to one is meaningful?
    • What user interface tools might you have used for the competition? (JSP 2.0 was used in their case.)
    • Does the competition represent real situations present in the industry, such that the conclusions are meaningful on a larger scale?
    • Is Spring really that powerful, to be the product that makes Java "as powerful as" its competition?

    Threaded Messages (186)

  2. Despite having a skeleton GUI and customized JSP tag files, this took us significantly more time than other teams that worked as fast as we did.
    Why did not you use DreamWeaver to create application UI and then just sprinkle it with few attributes in Spindle ?
  3. Choice of words[ Go to top ]

    During the 2005 Dutch RAD Race we proved that Java beats the .NET framework and measures up to the best RAD tool, without sacrificing quality and flexibility.

    Perhaps "demonstrated to be," or "claims," but "proved?" I don't think so. One contest is not a proof. To me, this single sentence taints the credibility of the entire article.

    Steve Punte
    JXReports
  4. Congratulations to Erwin Bolwidt and Vincent Partington for completing a challenging and interesting exercise.

    But these RAD contests seem a bit too me like hotdog-eating contests. Sure, if you work hard enough at them, you can probably win one, but at the end are you really happy with what you've accomplished?

    Embedding Hibernate sessions into JSP pages? This is what allows Java developers to 'catch up' with the competition? If we build an application that is completely impossible to change or refactor, will we finally demonstrate that we are as good as Rails?
  5. Lately there has been a lot of fuss about this kind of RAD development and that Java can not productive in this space. This kind of competition provides evidence that Java can be quite productive, and what is more important, all tools used are 'free'.
  6. OpenSessionInView filter[ Go to top ]

    I believe they are talking about Spring's OpenSessionInViewFilter. This allows seamless integration of JSP view-time rendering and Hibernate lazy loading. It's important to realise that it is used read-only, doesn't impact architectural layering and, as the authors point out, can be replaced (if desired) by more complexity in the DAO.

    I've used this technique also and used in this way it is not an impediment to refactoring.

    Regards

    John Hurst,
    Wellington, New Zealand
  7. Re: no hibernate sessions in JSPs![ Go to top ]

    D'uh, another victim of "insider tech talk". The Hibernate "Session in View"-interceptor is basically an AOP-interceptor implemented the old-fashioned way: as a servlet filter.

    In English that means: every HTTP-request gets a ThreadLocal that contains its very own Hibernate Session-instance (a Session is roughly the same as a JDBC-connection). This is accomplished through a servlet filter, hence the "view".

    This pattern works well as long as you: don't want to reuse your DAO-objects outside of a web application and don't mind having to either: eagerly load all associations, water down your data-persistence abstraction by reattaching domain objects to the session whenever needed or not really using associations. If this is a general shortcoming of Hibernate is another discussion. It's a drawback, but it's entirely not as bad as the scenario you describe. Also, it's a problem that the competition doesn't have a good answer for as well.

    cheers,
    -joh
  8. Re: no hibernate sessions in JSPs![ Go to top ]

    and here you go.. reading John Hurst's comment, I realize that I know too little about Spring. They have an entirely own definition of OpenSessionInView.

    argh!
    -joh
  9. It's great to see success stories about the productivity of "the new way" to do J2EE applications. It really seems like Spring has become the "killer app" for J2EE development. It is for me, certainly.

    Perhaps one would say Spring+Hibernate+etc etc etc. But for me I think Spring as the integration technology has made the biggest difference, because it has enabled and encouraged me to write applications the "right" way, but very productively.

    The Spring architectural principles are strong. We get not only ease of initial development, but also the kind of application that is easy to alter and enhance. This is key for enterprise development.

    Erwin and Vincent will find that their hot dogs don't make them puke the next day.

    Regards

    John Hurst
    Wellington, New Zealand
  10. Good news[ Go to top ]

    Congrats to this team. I blogged about the "Weak Points" section and how I hope Trails will be an effective answer.
  11. Spring Rules[ Go to top ]

    ORM==Quick and dirty

    1) Visual Studio .NET lost because they don’t use an ORM tool and that slows them down significantly.

    2) Congratulation to Spring, obviously they would have won if they had a layout tool like in VS .NET. Too bad that there are still so many in the Java world that cling so desperately to the old "Elephant EJB Servers"!

    Regards
    Rolf Tollerud
  12. Spring+ORM Rules[ Go to top ]

    ORM==Quick and dirty1) Visual Studio .NET lost because they don’t use an ORM tool and that slows them down significantly.2) Congratulation to Spring, obviously they would have won if they had a layout tool like in VS .NET. Too bad that there are still so many in the Java world that cling so desperately to the old "Elephant EJB Servers"!RegardsRolf Tollerud

    You have this the wrong way around. The Java with Spring approach DID use ORM: They used Hibernate. Spring has very strong support for ORM, including Hibernate and JDO.
  13. Spring+ORM Rules[ Go to top ]

    Reread my post.
  14. P.S.[ Go to top ]

    1) Visual Studio .NET could have won if they had used ORM.
    2) Spring could have won if they had had a layout manager.

    But none of this tools belongs to a serious project.
    IMO!

    also remember: Spring.NET exist
  15. P.S.[ Go to top ]

    1) Visual Studio .NET could have won if they had used ORM.2) Spring could have won if they had had a layout manager.But none of this tools belongs to a serious project.IMO!also remember: Spring.NET exist

    I should not have posted with a heavy cold. I apologise. Of course you agreed they used ORM. However, I don't quite understand why you say ORM = quick and dirty. You have frequently backed people who are against ORM: Much of EJB is to do with ORM. Also, there are layout tools for J2EE - Studio Creator.

    I do find it strange for anyone to say that Spring and Hibernate aren't relevant for serious projects (assuming I am not misreading you again).
  16. Well, it is Rolf[ Go to top ]

    Brother, don't expect Rolf to be serious.
  17. Well, it is Rolf[ Go to top ]

    Brother, don't expect Rolf to be serious.

    I am a hopeless optimist, I guess.
  18. Well, it is Rolf (!)[ Go to top ]

    Leo,
    "So I agree with the outcome in general that Spring plus
    hibernate speeds development up a great deal"
    <br><br>

    It speeds up development,yes. But for quality of code look no further than Alexanders Jerusamlem's post!

    <br><br>Steve,
    "Spring has very strong support for ORM"<br><br>

    Spring has support for everthing! So you can even do "quick and dirty" apps in Spring, great. But that is not its main purpose, or so I believe.

    <br><bSteve,"You have frequently backed people who are against ORM: Much of EJB is to do with ORM"

    Mats,
    Brother, don't expect Rolf to be serious.

    I am a hopeless optimist, I guess.


    How come that when Alexander says the same thing you "partly agree". But when I say it I am an unserious?

    <br><br>As I said, neither ORM nor "layout manager" belongs in serious projects.<br><br>
    Regards<br>
    Rolf Tollerud
  19. Well, it is Rolf (!)[ Go to top ]

    As I said, neither ORM nor "layout manager" belongs in serious projects.

    Regards

    Ah. So I guess EBay is not a serious project? They use ORM.
  20. Exceue me for being off topic but I just have to give Steve a couople of links.

    "Ruby on Rails and FastCGI: Scaling using processes instead of threads. Specifically, their

    perl+fastcgi+mysql solution scales to 50 million page views a day, 1000 per second at peak."

    http://www.jroller.com/page/obie/20050414
    and this,

    "My point is that the situation brewing does not bode well for average Java web developers,

    not at all"

    http://www.jroller.com/comments/obie/Weblog/unabashed_ruby_on_rails_enthusiasm

    Regards
    Rolf Tollerud
  21. "Ruby on Rails and FastCGI: Scaling using processes instead of threads. Specifically, their

    You will note that Ruby on Rails incorporates an ORM (well, that's what they call it anyway), which you say is inappropriate for serious uses. You are following your well-established pattern of giving examples which contradict yourself.
    perl+fastcgi+mysql solution scales to 50 million page views a day, 1000 per second at peak."
    http://www.jroller.com/page/obie/20050414
    and this,

    That is great until you have to do some actual serious processing of information, or need real reliability. The example they give is LiveJournal. You may or may not know about the recent serious downtime of that site, with 'sorry we are still working on it' messages appearing every few hours. Bad example then!

    It is easy to get something that is almost reliable and robust, but it is that final 5%,1%... 0.01% that requires a lot more work.
    "My point is that the situation brewing does not bode well for average Java web developers,

    not at all"
    http://www.jroller.com/comments/obie/Weblog/unabashed_ruby_on_rails_enthusiasm

    For the (how many is it now?) fourth time, let me remind you that quoting a single blog entry that happens to agree with you at does not constitute a serious argument. There are serious flaws in Ruby on Rails - fragile code, huge dependence on database schema (an ORM that dynamically maps the 'R' to the 'O' at runtime is ugly), problems with testing, performance, refactoring and debugging. It is a great quick-and-dirty way to get something up and running, but it is not a way to write large apps.

    Some fan's post which calls anyone who disagrees with them a 'cynical idiot' is not something I would take seriously.
  22. Castor[ Go to top ]

    ORM==Quick and dirty1) Visual Studio .NET lost because they don’t use an ORM tool and that slows them down significantly.2) Congratulation to Spring,

    Never fear, if you watch this Tech Ed session with Anders, way at the end he talks about some of the exciting new things they are looking in to working with over at Microsoft, and this is exactly what he is excited about.

    He mentions the usual "impedance mismatch" so he's got the terminology down, and I look forward to the exciting things they come up with, as it's fun to see them catch up to where Java was 5 years ago. Check out the Castor link below, as that's been around since 2000, I'm not sure about the zillion other mapping tools available in Java.

    He makes a couple weak jabs at Java (it's a hard language because it doesn't have IntelliSense? Isn't that part of the IDE?), but otherwise he's an engaging speaker.

    http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20040624csharpah/manifest.xml

    http://www.castor.org/presentations.html
  23. Perl/PHP achieves 50 million page views a day, Ruby on Rails, the D programming Language, .NET etc..
    "In all markets there are lots of low-cost solutions (predators) waiting for a mistake from the dominant player"

    So Microsoft is going to release their own ORM? So we can look forward to these horrible anti patterns for .NET too. Great!(NOT).

    Regards
    Rolf Tollerud
  24. Perl/PHP achieves 50 million page views a day,
    So Microsoft is going to release their own ORM? So we can look forward to these horrible anti patterns for .NET too. Great!(NOT).

    How many hits a day does EBay manage? It uses J2EE and an in-house written ORM; unquestionable evidence that ORM need not be inefficient or slow.
  25. Steve has lots of money[ Go to top ]

    And how much did it cost did you say?
  26. What relevance has this?[ Go to top ]

    And how much did it cost did you say?

    Look, you were wrong. You said that ORM did not belong in serious projects. I showed you a serious project (one of the best-known sites on the web) that uses ORM. I could have presented many others. Why not just admit your mistake instead of trying to change the subject?
  27. Why don't you try to keep your feet on the ground? "One billion dollar == one mall IBM project".
    By this time IBM has worked with more than one hundred consultants for three years. The mind is boggling trying to grasp the consequences or the cost.

    And this gargantuan project you compared to a simple Perl program! Where are you honesty and integrity? Where is your sense of proportions? Do you really think that TSS members are so stupid?

    You are comparing grandma's knitting budget with the NASA moon-expedition.

    Tell me that you are joking please?

    Regards
    Rolf Tollerud
  28. By this time IBM has worked with more than one hundred consultants for three years.

    And produced one of the most successful websites ever. Do you have actual figures for the number of consultants involved?
    The mind is boggling trying to grasp the consequences or the cost.

    The consequences was a phenomenally successful and highly profitable website. I have no idea of the cost. Do you have personal access to EBay's development budget?
    And this gargantuan project you compared to a simple Perl program! Where are you honesty and integrity? Where is your sense of proportions? Do you really think that TSS members are so stupid?

    I did not compare it to anything. I simply stated that it used J2EE and ORM. You said ORM was not suitable for serious projects. If you think that your example of LiveJournal is a 'simple PERL program'... where did you get that idea?

    As I said, LiveJournal can afford (and experiences) downtime and failure. Blogs are fun; a passtime. EBay can't afford that. That is why they use the technology they use. They use Java, J2EE, some aspects of EJB and ORM.
    You are comparing grandma's knitting budget with the NASA moon-expedition.

    I assume that major projects in PERL have no development costs at all?
    Tell me that you are joking please?

    About what? A simple, clear proof that you were wrong about ORM?
  29. I often complained about the attitude of the J2EE world and the Java programmers (pseudo scientific talk, vitriolic anti MS hyperbole, etc) but nothing disgust me more that this deliberate disregard of customer benefit, advocating projects and software far more expensive than currently low-cost solutions that could just as well do the job.

    Trust me, to find the best low-cost price/performance solution that will work for this particular customer and make him happy is a much more rewarding occupation.

    I hope you feel comfortable in your daily professional con-business.
  30. Please explain the relevance[ Go to top ]

    I often complained about the attitude of the J2EE world and the Java programmers (pseudo scientific talk, vitriolic anti MS hyperbole, etc) but nothing disgust me more that this deliberate disregard of customer benefit, advocating projects and software far more expensive than currently low-cost solutions that could just as well do the job.Trust me, to find the best low-cost price/performance solution that will work for this particular customer and make him happy is a much more rewarding occupation.I hope you feel comfortable in your daily professional con-business.

    Could you please explain exactly what relevance this has as evidence for the use or non-use of ORM in serious applications? Perhaps you could reconcile your dislike of ORM with your support of Ruby on Rails, Trails and Castle, all of which use (low cost) ORM?

    And finally, perhaps you could explain how this diversion into matters of performance and cost helps in any way to reconcile your statement that 'ORM does not belong to a serious project' with its use at sites such as EBay? Are you either saying that EBay is not a serious site, or that it does not use ORM? Please clarify.
  31. Rolf, please stop. I, like others, tire of reading arguments where you shift your position every time someone proves a point against you. Here's a breakdown of the argument between you and steve:
    ROLF: Nice article, but everyone knows ORM isn't used for serious applications.
    STEVE: Ebay uses ORM. Ebay is a serious application.
    ROLF: How much money did Ebay cost? I can't believe proponents of ORM would use this as an example! Billions of dollars! Inefficiencies!
    ROLF: Look at what Ruby on Rails can do!
    STEVE: You said ORM wasn't used for serious applications, I showed you a serious application. Not sure where Ruby on Rails came from.
    ROLF: I don't know how you can live with yourself charging clients the money you charge! Your ways are outdated and will soon go the way of the dodobird! Me and my mammalian cousins will feast upon your eggs! (OK, you didn't say that)

    I forget the official term for this kind of argument but it boils down to "if cornered on a point, make some noise about something else". You stated that ORM wasn't for serious use and this statement was refuted. You then attempted to undermine the "serious use" by saying it was costly. What you missed along the way (besides the fact that you completely changed arguments) was that any serious solution is eventually going to cost money. You can't criticize a mission critical application for its development cost, because heavy-duty reliability costs more than toy apps. The point about ORM is that it has as much a place within a simple, low-scale application, as it does in a costly, mission-critical one. There is nothing about ORM per se that would make it a poor choice in either situation.

    Don't worry, I don't expect you to "get" what I'm saying because it's pretty well laid out in a logical fashion. I'm waiting for the next assault from out of the blue on a completely different topic to save you from the simple fact that you avoided addressing one part of argument by raising a red herring about a completely irrelevant aspect of the information presented.

    I believe you will find that your clients will be happier and feel their benefit is not disregarded when they have a contractor or consultant who can think logically, admit to simple facts, not get easily confused by clear thinking, not get easily misled by marketing speak out of Redmond, not get religious about any technology choice, and carry on a coherent discussion without resorting to cop out tactics.
  32. Drew,

    No excuse me, it is not pseudo science, anti MS rants or even cheating customers I dislike most with the J2EE camp. No I think that this prize must go to the unbelievable ability or capacity to believe your own unclear/fuddy reasoning that completely lack of logic, reason and common sense.

    For your own benefit listen. You have not won any discussion. On the contrary you are making a fool of yourselves. With enough money you can do anything. But in the real world there is always shortage of that commodity and price/performance is paramount. To refer to eBay, the most expensive project in IT history is ridiculous. To even try to claim that J2EE has anything to do with eBay's business idea is even more ridiculous.
  33. P.S.[ Go to top ]

    To spell it out: eBay would have been equally successful with anyone of a dozen other technologies. The only difference is that they would have saved hundreds of millions of dollar.
  34. But is Ebay a serious application? And is it using ORM? Then you were wrong in your first point. As long as Ebay is still up and running, regardless of whatever else you might think about anything in the world, your point that "ORM can't be used for any serious application" is wrong. Where along the way did ebay become the most expensive project in history? Never mind, don't answer, because it has zero relevance to the question of whether ORM can be used in serious applcations.

    Your second point, your red herring, is regarding some phantom charge of rampant costs associated with J2EE. You use this often any time something comes up on this site that you don't like or understand, and assume that anyone who disagrees with you can thus be lumped into the group of fools who blindly use every J2EE pattern that Sun or IBM tells them to. Any technology can be used incorrectly and in such a way that it costs far more than it should. The J2EE camp is not alone in this. Microsoft technologies have been used just as injudiciously with just as disastrous results. As the ORM opponents elsewhere in this topic have agreed with the ORM supporters, any technology can be used poorly and none is a panacea. As I hinted at before, lack of clear reasoning ability on the part of consultants is also a good way to make sure costs get out of hand.

    While I agree that some J2EE "patterns" are really overbearingly expensive and poor choices, I find it odd that you go off on a rant regarding how bad J2EE is while in a topic regarding spring and other more lightweight approaches to development. I also find it funny that you accuse others of unclear reasoning or common sense. I suppose now it's time to switch back to the "not for real applications" argument now that I'm calling you on lightweight versus heavyweight?

    Good luck in your endeavors to straighten everyone out here on TSS. Won't happen though I'm sure we'll disagree as to why.
  35. Good luck in your endeavors to straighten everyone out here on TSS. Won't happen though I'm sure we'll disagree as to why.

    It's a ninja thing.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  36. It all started with ORM[ Go to top ]

    1) A cheap and very simple Perl program ashives 50 million page views a day, 1000 per second at peak, with fastCGI.

    2) TSS members points out that they can do the same with one billion dollar.

    3) Friend of order points out that the answer lacks any common logic or sense of proportions.

    4) TSS members say that the critic doesn't keep to the subject, and is generally an idiot.

    BTW. Did you read my links?
    http://blogs.codehaus.org/people/tirsen/archives/001041_ruby_on_rails_and_fastcgi_scaling_using_processes_instead_of_threads.html

    As a web developer for almost a decade at this point I still see rails as a superior environment for 95% of the web apps out there, for the other 5% jvm or .net might be appropriate.

    http://www.jroller.com/comments/obie/Weblog/unabashed_ruby_on_rails_enthusiasm

    My point is that the situation brewing does not bode well for average Java web developers, not at all. First of all, there are dozens of Java web application frameworks and they all SUCK.

    It all started with ORM. It was ORM part in EJB that led you astray.

    Regards
    Rolf Tollerud
  37. Alone in the cold[ Go to top ]

    Hehe Rolf,
    I'm glad you waste so much time posting meaningless comments here - means you're writing less code.
  38. It all started with ORM[ Go to top ]

    1) A cheap and very simple Perl program ashives 50 million page views a day, 1000 per second at peak, with fastCGI.

    Ignoring my point that this not-so-simple Perl-based site has recently had serious downtime, and connection problems. But then with a blogging site this does not matter that much. Who cares if a transaction vanishes off into the ether? Its only a few words and can be posted again.
  39. I just got an idea for a TSS feature. How 'bout having a "hide this tread" button/link? Then I could choose to be entertained by Rolf or not.

    But I didn't know eBay used a home-grown ORM, so I guess it maybe was worth the read after all.
  40. ”But I didn't know eBay used a home-grown ORM, so I guess it maybe was worth the read after all”

    It do seem that it is difficult to get it right, don't it? If you are clueless and incompetent it doesn't help that people throw money at you. It just do not exist a case where it is correct to write your own ORM.

    Funny thing is that I remember distinctly how the much the eBay people was impressed by the IBM in the beginning. "You understood directly that they had a deep knowledge of J2EE", "they knew what they were talking of".

    The maybe knew what they were talking of but they certainly didn't knew what they was doing! ;)

    "How 'bout having a "hide this tread" button/link?"

    And then you would not have my links either. Don't you think that it was at least some interesting things to read?

    Regards
    Rolf Tollerud
  41. It just do not exist a case ...
    Say what you want about Rolf but he knows his english. This is not Rolf.
  42. It just do not exist a case where it is correct to write your own ORM. Funny thing is that I remember distinctly how the much the eBay people was impressed by the IBM in the beginning. "You understood directly that they had a deep knowledge of J2EE", "they knew what they were talking of".

    As I understand it, eBay already had an ORM before they installed J2EE, so there was no point in changing. They still used other aspects of EJBs though.
    It just do not exist a case where it is correct to write your own ORM.

    Interesting. So you don't approve of Ruby on Rails then. Because that was a home-grown ORM developed for the Basecamp application.
    The maybe knew what they were talking of but they certainly didn't knew what they was doing! ;)

    I hope any potential clients of yours see this:

    "Rolf says eBay+IBM didn't know what they were doing!"

    Reductio ad Absurdum I think. From now on any FUD or argument you put forward can be easily countered by referring to this opinion.
  43. So Microsoft is going to release their own ORM? So we can look forward to these horrible anti patterns for .NET too. Great!(NOT). RegardsRolf Tollerud

    You just finished saying that .NET lost because it had no ORM. Now it is an antipattern. So, .NET lost to an antipattern - sweet.
  44. Castor[ Go to top ]

    He makes a couple weak jabs at Java (it's a hard language because it doesn't have IntelliSense? Isn't that part of the IDE?), but otherwise he's an engaging speaker.
    I did a quick read on the session. Wow. He knows very little about AOP. I read a Code magazine discussion on it too (Mar/Apr issue) and they seem to know little to. They think Attributes is the same thing. (And Ted, from ServerSide.Net was part of the conversation).

    And as for his taking Intelliscence away and it being like Java? I HOPE he was kiding. Hmmm. What do you have to do in VS.Net to get Using statements? How about import statements in Eclipse/Idea/Netbeans? Nuff said there. Ok, a little more. In a previous statement he derided AOP becuase he didn't want to be tied to anyone IDE.

    The sad thing - he is not the only one who thinks this. People still think you have to code Java in VI and that everyone is doing it.

    He might be a smart man, but he defintely is not perferct or all-knowing.
  45. Well,

    Offcourse these challenges are debatable in the outcome of
    it. But simular contests in the past held in the Netherlands usually had java teams come in LAST or close to that !

    So I agree with the outcome in general that Spring plus
    hibernate speeds development up a great deal. As far as the gui is concerned there is still room for improvement for sure but all in all i believe this is indeed good news for all.

    Greetz
    Leo
  46. Every time I see these ORM solutions I can't help thinking that something with this object orientation idea has gone awfully wrong. As an example, let's look at two of the classes they present in this contest: BaseTrip and Trip. BaseTrip is generated by a tool. Trip is apparently hand coded.

    What do these two classes do? BaseTrip contains exclusively getters, setters and adders. It mimics a generic data structure that holds trip data and three sets of different types of reservations. What is achieved by generating this code is that it is type safe. Trip extends BaseTrip and adds what we so proudly call "business logic". Let's look at this business logic. Here it is:

     public BigDecimal getPrice() {
         BigDecimal totalPrice = new BigDecimal(0);

         totalPrice = totalPrice.add(applyDiscount(getFlightReservationsPrice(),
                 getFlightDiscountPercentage().intValue()));
         totalPrice = totalPrice.add(applyDiscount(getCarReservationsPrice(),
                 getCarDiscountPercentage().intValue()));
         totalPrice = totalPrice.add(applyDiscount(getHotelReservationsPrice(),
                 getHotelDiscountPercentage().intValue()));

         return totalPrice;
     }

     private BigDecimal getFlightReservationsPrice() {
         BigDecimal totalPrice = new BigDecimal(0);
         Iterator rs = getFlightReservations().iterator();
         while (rs.hasNext()) {
             FlightReservation r = (FlightReservation) rs.next();
             totalPrice = totalPrice.add(r.getPrice());
         }
         return totalPrice;
     }

     private BigDecimal getCarReservationsPrice() {
         BigDecimal totalPrice = new BigDecimal(0);
         Iterator rs = getCarReservations().iterator();
         while (rs.hasNext()) {
             CarReservation r = (CarReservation) rs.next();
             totalPrice = totalPrice.add(r.getPrice());
         }
         return totalPrice;
     }

     private BigDecimal getHotelReservationsPrice() {
         BigDecimal totalPrice = new BigDecimal(0);
         Iterator rs = getHotelReservations().iterator();
         while (rs.hasNext()) {
             HotelReservation r = (HotelReservation) rs.next();
             totalPrice = totalPrice.add(r.getPrice());
         }
         return totalPrice;
     }

     private BigDecimal applyDiscount(BigDecimal basePrice,
             int discountPercentage) {
         if (discountPercentage == 0) {
             return basePrice;
         } else {
             return basePrice.multiply(
                     new BigDecimal(100 - discountPercentage)).divide(
                     NumericUtil.BIG_HUNDRED,
                     2, NumericUtil.ROUNDING_MODE);

         }
     }

    So what this does is calculate the price of a trip by summing up the various reservations and applying discount percentages.

    Now, let's sum up what had to be done to get to this point:

    * Hibernate was configured in the container.
    * A Hibernate mapping was written (how many lines of code?).
    * Eclipse mapping toolset was configured and used to generate the code of 4 classes.
    * A custom class, extending the generated class was hand coded. This class has 128 lines of code.

    Now, please somebody tell me that this cannot be done in a single SQL statement. And then somebody please tell me that the procedural code above is somehow more maintainable than that single SQL statement.

    Hundereds of lines of code (including Java source, configurations and mapping code) were written just so that lots of data can be loaded from the database over the network into the application process with the sole aim of looping over three different sets and doing calculations of the most ugly kind (see applyDiscount), and all this to replace a single SQL statement. Writing procedural looping code over sets instead of using a declarative set oriented language that is readily available, is unproductive and error prone.

    I am aware that some of this code is reused for other purposes. The mappings are also used to store the data, which is a useful application of ORM. But I think the kind of procedural code, printed above, is a clear misuse of ORM. It is an antipattern. It is inefficient and it is inflexible.

    All the data centric applications I have written in my life use screens that show partly overlapping information. Generating static classes that mirror the data model and loading all these objects (lazily or not) every time a single field is required in any of the screens, is inefficient. What should be loaded is the data required for a particular screen, not an object graph full of mostly useless information.

    I know there will be people who accuse me of being old fashioned for advocating the use of SQL instead of objects. But that's not the case. I have been using OO intensively since the beginning of the 1990ies and I appreciate its usefulness for many tasks. But firstly, OO is most certainly older than the relational model, and secondly the world doesn't end with either OO or RDM. The case for using one or the other or a completely different model, has to be made based on merit, not on ideology. And it has to be questioned from time to time. For me ORM is the point where I feel a strong need for questioning the way OO is used for everything.

    It should be allowed to think about the best ways of writing data centric applications. For many such applications, I think there is a strong case for the separation of data and procedural code. There is a strong case for working declaratively and set oriented instead of prcedurally. And there is a strong case for making use of the flexibility of dynamic generic data structures as opposed to static (fixed at compile time) aggregates of code and data each one encapsulated by its very own custom API.

    This kind of code has to be hand coded and hand optimized without the use of indexes (or with procedurally maintained ones) and without the benefit of a statistics driven optimizer. Slicing and dicing, transforming, filtering, aggregating, analyzing data and declaratively expressing business rules is made very hard by static object models, despite these things are arguably being the very purpose of many data centric applications.

    I am convinced that the reason for the lack of productivity in many Java projects is this combinaton of OO misuse that ignores the capabilities of DBMS and a static language that doesn't allow the runtime manipulation of classes. There has to be a better way. Let's not be mislead into thinking that everything can be solved by loads of new frameworks and tools that are only slight variations of the ones that came before. Sure, some of them help. But sometimes they only help to hide the fundamental problems.
  47. I agree most of your comments but they have nothing to do with Spring.

    Spring in fact allows to use different approaches: If plain JDBC is good you can use it. If you believe that writing hand-crafted SQL is what you really need (as I think it is in most cases esp. in legacy or database-driven projects) you can use iBatis. Spring provides a very convergent medium in which you only have to only deal with certain kinds of abstractions.

    To sum up,
    Use Spring Be Happy!
  48. Every time I see these ORM solutions I can't help thinking that something with this object orientation idea has gone awfully wrong.

    [.. A large amount of a great post removed... ]

    I am convinced that the reason for the lack of productivity in many Java projects is this combinaton of OO misuse that ignores the capabilities of DBMS and a static language that doesn't allow the runtime manipulation of classes. There has to be a better way. Let's not be mislead into thinking that everything can be solved by loads of new frameworks and tools that are only slight variations of the ones that came before. Sure, some of them help. But sometimes they only help to hide the fundamental problems.

    I agree with you.. slightly.

    Firstly, I can't see how the relative ages of OOP and Relational Theory have any relevance (anyway, it's common knowledge that OOP only came into widespread use in the mid 80s).

    Secondly, the matter of lines of code is, I think, also irrelevant, if most or all of it is generated. I think the use of tools and frameworks is absolutely central to productivity. Productivity is measured by what you have to think about, and actually code and change to produce the application. For example, the ORM tool I use generates most of the code. If this code isn't written, and it can be automatically changed, it doesn't count in terms of productivity.

    One particular point I would like to discuss:
    Generating static classes that mirror the data model and loading all these objects (lazily or not) every time a single field is required in any of the screens, is inefficient. What should be loaded is the data required for a particular screen, not an object graph full of mostly useless information.

    This is not the way good ORMs work these days. Loading can be tuned and efficient, and you don't end up loading large and unnecessary object graphs.

    Anyway, where I agree strongly is with the criticism of how the processing looks and is done in the Java code you present, and in general. I have always felt that Java is a poor language for expressing business logic. (I wish Sun had allowed the use of operators for BigDecimal etc). I have a strong interest in the potential for the use of dynamic languages like Groovy for this purpose. I would find a combination of Groovy + JDO to be very useful.

    I think this is the way forward - to combine the power of dynamic languages, the libraries of Java, and the portability of ORM.
  49. I agree with you.. slightly. Firstly, I can't see how the relative ages of OOP and Relational Theory have any relevance (anyway, it's common knowledge that OOP only came into widespread use in the mid 80s).

    It is indeed irrelevant. I brought it up only because I have been attacked by people claiming that relational is somehow more old fashioned than OO instead of discussing the respective merits of the two models for particular problems.
    Secondly, the matter of lines of code is, I think, also irrelevant, if most or all of it is generated.

    That's a big if, however. The code I posted here (the whole file has 128 lines) is _not_ generated. It is a manually coded replacement of a single SQL statement.
    Productivity is measured by what you have to think about, and actually code and change to produce the application. For example, the ORM tool I use generates most of the code. If this code isn't written, and it can be automatically changed, it doesn't count in terms of productivity.

    I agree with that to some degree. What counts is the code you have to touch, the abstractions in which you think and the way these abstractions are represented in the "code". In my view, a calculation like the one I quoted should not be thought of in terms of loops and ifs but rather in terms of a single formula/expression. ORM very often leads to the wrong type of thinking. It leads us to think in terms of what objects do I need, when do I need them, when do I call this or that method, how do I navigate from here to there. That's not how business rules should be thought of most of the time. It's a very low level abstraction.

    And with respect to code generation, I do agree with you that it doesn't count in terms of lines of code. But don't forget that code generated at compile time cannot be changed at runtime. It's static. Sometimes that's OK, but in most data centric applications, I want to be able to flexibly manipulate data structures at runtime and not write (or generate) a single static class for each and every structural permutation. And also don't forget that the classes that are generated by ORM tools are not free in terms of productivity. You have to describe the mappings to make it all happen, otherwise all you get is a copy of the relational data model.
    One particular point I would like to discuss:
    Generating static classes that mirror the data model and loading all these objects (lazily or not) every time a single field is required in any of the screens, is inefficient. What should be loaded is the data required for a particular screen, not an object graph full of mostly useless information.
    This is not the way good ORMs work these days. Loading can be tuned and efficient, and you don't end up loading large and unnecessary object graphs.

    I'm not familiar with each and every technique that may be available in particular ORM tools (as I said I'm aware of lazy loading and so on but that doesn't convince me at all). What I see is how ORM tools are used in practice and that says a lot about what they make easy and what they make hard. Runtime efficiency is certainly not the biggest issue (although it can be in particular situations). The biggest problem is that a lot of code is unnecessarily written using low level procedural means.

    What I see is that people use loops instead of expressions and procedural object graph navigation instead of joins. People write nested loops instead of using group by, they manage running totals like in the 1950ies, they sort data in memory without using indexes, etc.

    I know that ORM tools don't force you into doing that. They all have query languages. But the reason for their existence is that people want to do everything in an object oriented way and thus try to eliminate queries, make the relational schema transparent and avoid set operations. It's not the tool's fault. The tool is just a symptom of the wrong model of thinking applied to data centric applications.
  50. The biggest problem is that a lot of code is unnecessarily written using low level procedural means.What I see is that people use loops instead of expressions and procedural object graph navigation instead of joins. People write nested loops instead of using group by, they manage running totals like in the 1950ies, they sort data in memory without using indexes, etc. I know that ORM tools don't force you into doing that. They all have query languages. But the reason for their existence is that people want to do everything in an object oriented way and thus try to eliminate queries, make the relational schema transparent and avoid set operations. It's not the tool's fault. The tool is just a symptom of the wrong model of thinking applied to data centric applications.
    Well, I don't agree with that. ORM tools are the piece that's missing which will allow us to have the best of BOTH worlds. You shouldn't be restrained to the set operations of the relational model, as much as you shouldn't do dataset ordering and managing running totals within your in-memory objects. ORM tools will allow us to leverage and bridge both worlds, this is not an either-or situation. So for a well designed system, objects would be doing domain logic only when adequate, and set operations and other relational model "oriented" operations should be relegated to the database. ORM tools comes into the scene to facilitate this balancing of responsabilities, not to hide the database from the rest of the system. IMO this is the biggest misunderstanding people have about ORM tools: ORM tools don't free you from knowing SQL.

    Regards,
    Henrique Steckelberg
  51. The biggest problem is that a lot of code is unnecessarily written using low level procedural means.What I see is that people use loops instead of expressions and procedural object graph navigation instead of joins. People write nested loops instead of using group by, they manage running totals like in the 1950ies, they sort data in memory without using indexes, etc. I know that ORM tools don't force you into doing that. They all have query languages. But the reason for their existence is that people want to do everything in an object oriented way and thus try to eliminate queries, make the relational schema transparent and avoid set operations. It's not the tool's fault. The tool is just a symptom of the wrong model of thinking applied to data centric applications.
    Well, I don't agree with that. ORM tools are the piece that's missing which will allow us to have the best of BOTH worlds. You shouldn't be restrained to the set operations of the relational model, as much as you shouldn't do dataset ordering and managing running totals within your in-memory objects. ORM tools will allow us to leverage and bridge both worlds, this is not an either-or situation. So for a well designed system, objects would be doing domain logic only when adequate, and set operations and other relational model "oriented" operations should be relegated to the database. ORM tools comes into the scene to facilitate this balancing of responsabilities, not to hide the database from the rest of the system. IMO this is the biggest misunderstanding people have about ORM tools: ORM tools don't free you from knowing SQL.Regards,Henrique Steckelberg

    I agree with you in theory. My problem is that most of the time when I look at code that uses ORM, I feel that the balance is quite wrong, as with the code I posted above. That's not the way prices should be calculated in my view.
  52. ORM very often leads to the wrong type of thinking. It leads us to think in terms of what objects do I need, when do I need them, when do I call this or that method, how do I navigate from here to there. That's not how business rules should be thought of most of the time. It's a very low level abstraction.

    I agree that ORM can lead to the wrong type of thinking, but I think that is true of any approach. I don't think it is necessarily low level.
    Sometimes that's OK, but in most data centric applications, I want to be able to flexibly manipulate data structures at runtime and not write (or generate) a single static class for each and every structural permutation.

    You don't have to with a modern ORM.
    What I see is how ORM tools are used in practice and that says a lot about what they make easy and what they make hard.

    I see what you are saying, but the same could be said for much use of relational databases. Lack of expert understanding of relational theory can produce just as many horrors and poor use of ORM.
    People write nested loops instead of using group by, they manage running totals like in the 1950ies, they sort data in memory without using indexes, etc. I know that ORM tools don't force you into doing that.

    They certainly don't, but I agree there is much inappropriate use.
    They all have query languages. But the reason for their existence is that people want to do everything in an object oriented way and thus try to eliminate queries, make the relational schema transparent and avoid set operations.

    I don't think you can generalise what people use ORM for. I don't use ORM for this reason. I use it so that I can (1) express things in an OOP way when that is clearer, (or in a portable query language if that is clearer), and (overwhelmingly) (2) because I get real, effective portability of my code. I get an 'isolation layer' from the considerable vendor-specificity of different databases and stores. This may not be an important consideration for many, but it is for me.
  53. I don't think you can generalise what people use ORM for. I don't use ORM for this reason. I use it so that I can (1) express things in an OOP way when that is clearer, (or in a portable query language if that is clearer), and (overwhelmingly) (2) because I get real, effective portability of my code. I get an 'isolation layer' from the considerable vendor-specificity of different databases and stores. This may not be an important consideration for many, but it is for me.

    Of course you're right. There are legitimate reasons to use ORM and I'm sure many poeple who have thought about the issues, like yourself, make good use of it. I just happen to think that considering ORMs many opportunities for misuse, there is noticably little debate about ORM anti patterns.
  54. just happen to think that considering ORMs many opportunities for misuse, there is noticably little debate about ORM anti patterns.

    You are right; such debate could be highly useful, and may help reduce misunderstanding on all sides of the Relational/Object argument.
  55. What I see is that people use loops instead of expressions and procedural object graph navigation instead of joins. People write nested loops instead of using group by, they manage running totals like in the 1950ies, they sort data in memory without using indexes, etc.

    I know that ORM tools don't force you into doing that. They all have query languages. But the reason for their existence is that people want to do everything in an object oriented way and thus try to eliminate queries, make the relational schema transparent and avoid set operations. It's not the tool's fault. The tool is just a symptom of the wrong model of thinking applied to data centric applications.

    I think this statement is an over-generalization. I, for example, don't use Hibernate because I'm interested in doing OO for the sake of OO. As someone who used raw JDBC, I find that Hibernate makes my job easier. It saves me from grunt work while, for the most part, giving me the tools I need to "get dirty" when I need to.

    I wouldn't use it unless my job was easier for it. And if it keeps my code clean in the process, so much the better.
  56. What I see is that people use loops instead of expressions and procedural object graph navigation instead of joins. People write nested loops instead of using group by, they manage running totals like in the 1950ies, they sort data in memory without using indexes, etc.

    Almost forgot, I'm fairly sure that pretty much all the ORMs allow for joins and aggregates. Certainly, Hiberanate provides these features.
  57. What I see is that people use loops instead of expressions and procedural object graph navigation instead of joins. People write nested loops instead of using group by, they manage running totals like in the 1950ies, they sort data in memory without using indexes, etc.
    Almost forgot, I'm fairly sure that pretty much all the ORMs allow for joins and aggregates. Certainly, Hiberanate provides these features.

    I'm not saying that ORM prevents you from doing anything. What I'm saying is that a lot of patterns that ORM makes easy are really anti patterns. The code I posted here is a case in point.
  58. The code I posted here is a case in point.
    Any why is that?

    As you read in the article, the goal was to make a serious application in two days. This is as serious as it gets. Within the requirements (the dataset), this is a good and workable approach. It might look a bit ugly because of the BigDecimals, but anyone who has written financial applications and knows how floating point numbers work, knows that they don't match. Given BigDecimal arithmetic, there is absolutely nothing wrong with the code.

    Architecturally, it is sound, because it is easily replaced with an SQL statement (people who don't know ORM tools like hibernate might not understand this at first, being used to putting SQL inflexiblhy in their code instead of in a mapping file), without changing the code that calls the method.

    Anyone who seriously thinks they can write a CRUD application like this in Java (with some slightly more advanced business logic added, as in this case) without an ORM layer directly in SQL, is welcome to take up the challange. You'll loose.

    Hibernate has enough hooks to allow optmized SQL to be inserted in most location when this is necessary. But you don't optimize when this is not needed. Not in a throwaway application, and not in a serious business application. When you have limited time, you spend it wisely on the most important issues, in all cases.
  59. I'm not critisizing the application as a whole and I'm not arguing about the correct place where the SQL should be put. There are many feasable places and if an ORM tool has a good place for it, then all the better.

    What I'm arguing with is quite simply that you write tens of lines of procedural code for something that can be done declaratively in a fraction of the code and with a fraction of the complexity and possibilities for error. And this is symptomatic for how code written by ORM users often looks. I'm not saying that ORM cannot be used in another way. But you used it in this way, and with respect, I think this is a bad design decision.
  60. two schools of OO[ Go to top ]

    The biggest problem is that a lot of code is unnecessarily written using low level procedural means.What I see is that people use loops instead of expressions and procedural object graph navigation instead of joins. People write nested loops instead of using group by, they manage running totals like in the 1950ies, they sort data in memory without using indexes, etc. I know that ORM tools don't force you into doing that. They all have query languages. But the reason for their existence is that people want to do everything in an object oriented way and thus try to eliminate queries, make the relational schema transparent and avoid set operations. It's not the tool's fault. The tool is just a symptom of the wrong model of thinking applied to data centric applications.

    In the Java ORM world, data entities are treated as (or "mapped to") objects. In the ADO.NET world, RDBMS elements are treated as objects, such as DataSets, Tables, Rows, Views etc.

    Which is more OO? Does it matter? As long as both work. However, to go to the OO extreme will only compromise the power of SQL and relational database and make the application more complicated than necessary.
  61. In my POV it all boils down to maintanability. Yes, it could be faster to do it all with SQL statements. But then everything will be so tied it will be dificult to refactor code to implement new features, for example. An ORM tool can help lower the coupling between your code and your database, making both more easily maintanable. So it is not just about coding speed, there must be a balance with maintenance and performance too. ORM tools can help with the later too, with caching, distributing and other features these tools usually offer. All this results in a system with a better scalability and maintanability, so calling ORM quick-and-dirty is incorrect, IMO.

    Regards,
    Henrique Steckelberg
  62. In my POV it all boils down to maintanability. Yes, it could be faster to do it all with SQL statements. But then everything will be so tied it will be dificult to refactor code to implement new features, for example.
    No, that is plainly wrong. If handled in a componentized manner it will be exceedingly easy to implement new features, because "doing it all in sql" does not necessarily mean "having sql all over the place and need to know the data model all over the place".
     An ORM tool can help lower the coupling between your code and your database, making both more easily maintanable.
    YAPM (Yet Another Programming Myth). Insert a required field into any table and see your program go belly up.
     So it is not just about coding speed, there must be a balance with maintenance and performance too. ORM tools can help with the later too, with caching, distributing and other features these tools usually offer.
    I like the caching stuff. Usually caching is so overused it drives me to tears, the lookup times in the in memory caches almost equalling the round trip times to the database. And besides you will get all the overhead of keeping the cache in sync...
     All this results in a system with a better scalability and maintanability, so calling ORM quick-and-dirty is incorrect, IMO.Regards,Henrique Steckelberg

    Now that should not give you the impression that I don't like ORM.... In fact I like it very much as a RAD way to put something together. Kind of like the old days of "prototyping" with VB. I think it is nice and intellectually challenging. However one of the things that really really puzzles me is that we do have a perfect and simple abstraction to talk about data (called tables and relations), we have an efficient yet easy to understand way of getting to the data (joins). A state of the art database will even give you a way of providing business logic in the database (called PL/SQL or what have you). What we don't have (strangely) is a nice abstraction for updateing data (update is a bit clumsy). Doesn't really make a case for an ORM tool for me, especially when taking the transactional aspects in account.

    Most of the time "ORM" is used because of fear (we need to be able to switch between databases, because we don't know if mysql is good enough (HELL, TEST IT!!) for us/we don't know if we can afford oracle...). The strange thing is (just my experience): The money you will safe by using one database product only and use it proper will always be a lot larger than the overhead you'll produce by being "independent".
  63. In my POV it all boils down to maintanability. Yes, it could be faster to do it all with SQL statements. But then everything will be so tied it will be dificult to refactor code to implement new features, for example.
    No, that is plainly wrong. If handled in a componentized manner it will be exceedingly easy to implement new features, because "doing it all in sql" does not necessarily mean "having sql all over the place and need to know the data model all over the place".

    Interesting. When I did program in VB, the data model was everywhere, becase the UI was tied directly to the queries. In Java, above the DAO I only have objects, and I put the logic in those objects as appropriate (and I usually get a graph of them out of the database, not just a list).
    How is your architecture?

    Insert a required field into any table and see your program go belly up.

    Insert it in the mapping file and have the database structure and the code updated at the same time...
    I think it is nice and intellectually challenging. However one of the things that really really puzzles me is that we do have a perfect and simple abstraction to talk about data (called tables and relations), we have an efficient yet easy to understand way of getting to the data (joins).

    And no place to put the business logic... besides the DAO's maybe?
    A state of the art database will even give you a way of providing business logic in the database (called PL/SQL or what have you).

    Funny... I rarely install my apps twice in a row on the same database. When I go to the client their IT manager tells me what database they use, I usually cannot choose another.
    Thus, I cannot use stored procedures unless they are few and there are compelling performance reasons to use them.
  64. In my POV it all boils down to maintanability. Yes, it could be faster to do it all with SQL statements. But then everything will be so tied it will be dificult to refactor code to implement new features, for example.
    No, that is plainly wrong. If handled in a componentized manner it will be exceedingly easy to implement new features, because "doing it all in sql" does not necessarily mean "having sql all over the place and need to know the data model all over the place".
    "Doing it in a componentized manner" is another name for ORM. :)
    &nbsp;An ORM tool can help lower the coupling between your code and your database, making both more easily maintanable.
    YAPM (Yet Another Programming Myth). Insert a required field into any table and see your program go belly up.
    I said "lower coupling", not "get completely rid of coupling". Of course it will affect you program, but it may be easier to make changes, as others have explained.
    &nbsp;So it is not just about coding speed, there must be a balance with maintenance and performance too. ORM tools can help with the later too, with caching, distributing and other features these tools usually offer.
    I like the caching stuff. Usually caching is so overused it drives me to tears, the lookup times in the in memory caches almost equalling the round trip times to the database. And besides you will get all the overhead of keeping the cache in sync...
    &nbsp;All this results in a system with a better scalability and maintanability, so calling ORM quick-and-dirty is incorrect, IMO.Regards,Henrique Steckelberg
    Now that should not give you the impression that I don't like ORM.... In fact I like it very much as a RAD way to put something together. Kind of like the old days of "prototyping" with VB. I think it is nice and intellectually challenging. However one of the things that really really puzzles me is that we do have a perfect and simple abstraction to talk about data (called tables and relations), we have an efficient yet easy to understand way of getting to the data (joins).
    Perfect and simple? It may be simple, but it is not perfect. Try to map a complex hierarquical model to a relational database and you will understand. I am not saying it can't be done, I am saying it won't be a perfect fit, almost to the point it may look like a hack, an anti-pattern. I am not against relational model, I am against adopting it as the ultimate super-duper solution to all IT problems. As I said, we should be able to correctly balance the power of relational with the power of objects, and IMO ORM tools may help achieve that.
     A state of the art database will even give you a way of providing business logic in the database (called PL/SQL or what have you). What we don't have (strangely) is a nice abstraction for updateing data (update is a bit clumsy). Doesn't really make a case for an ORM tool for me, especially when taking the transactional aspects in account. Most of the time "ORM" is used because of fear (we need to be able to switch between databases, because we don't know if mysql is good enough (HELL, TEST IT!!) for us/we don't know if we can afford oracle...). The strange thing is (just my experience): The money you will safe by using one database product only and use it proper will always be a lot larger than the overhead you'll produce by being "independent".
    Let's not prohibit chainsaws just because some people misused them. Better educate people about how use them safely. Meanwile you can keep using your old "hand-driven" saws to cut the whole forest down (joking!). :)
  65. Most of the time "ORM" is used because of fear (we need to be able to switch between databases, because we don't know if mysql is good enough (HELL, TEST IT!!) for us/we don't know if we can afford oracle...). The strange thing is (just my experience): The money you will safe by using one database product only and use it proper will always be a lot larger than the overhead you'll produce by being "independent".

    Being able to switch any part of your IT system (in fact, being able to switch any part of your business) is good practice, plain and simple. It allows you to competitively tender for suppliers and switch in case of problems. You may get so far with a MySQL implementation, then find that your customer would rather use PostgreSQL or Oracle. Well fine; with a good ORM like Hibernate that should only involve minor changes. With JDO you can even change your ORM vendor (this will be possible with Hibernate when EJB 3.0 is finalised). It is my view that for anything but the smallest projects portability and vendor-independence should be a significant consideration for any IT development. I have seen too many projects hit a dead end or slowly die because they were too tied in to a particular vendor.

    With relational databases there are two choices to get portability: either write a limited subset of SQL that all vendors support (you might have to spend some time finding out exactly what that subset is). However, this is wasteful as you aren't using the full features of what might be an expensive DBMS. The alternative is to use a high-quality ORM that has built-in knowledge of a range of databases, and can automatically use non-standard features and SQL where appropriate to optimise use of the database. You can use the query languages of these ORMs to access and process information declaratively, much like SQL, but with the advantage of portability.
  66. In my POV it all boils down to maintanability. Yes, it could be faster to do it all with SQL statements. But then everything will be so tied it will be dificult to refactor code to implement new features, for example. An ORM tool can help lower the coupling between your code and your database, making both more easily maintanable. So it is not just about coding speed, there must be a balance with maintenance and performance too. ORM tools can help with the later too, with caching, distributing and other features these tools usually offer. All this results in a system with a better scalability and maintanability, so calling ORM quick-and-dirty is incorrect, IMO.Regards,Henrique Steckelberg

    Well, I didn't say it was quick and dirty. But I think 50 to 70 lines of procedural code, sprinkled through various classes, containing multiple loops to replace a single delcarative statement for calculating the price of something, is not more maintainable. On the contrary, it is an absolute atrocity. The maintainance you want to achieve in this case, is to be able to easily change the way the price is calculated.

    I don't argue with other merits of ORM like caching or DBMS independence. I'm not arguing against a technology. All I'm saying is that something like a mathematical formula should be expressed as a declarative expression (if possible), not by lots of procedural code. And that a join is preferable to looping and branching code.
  67. You're forgetting something. Not everything is database-tied. The code you're talking about works perfectly when you are building a Trip, without having to write it to the database.

    Database-driven code only works when the data is actually in the database.

    When you're building an object-tree in a user-interface, you don't always want to write every single change to the database. (That varies with the requirements - of course persisting every changes allows recovery if the application crashes, but it is slower and less flexible, and not a requirement in quite a few cases)

    But how would you write the code? You sprinkle your posts with words like "atrocity", when you describing perfectly normal Java code. I don't see how inserting SQL statements through your Java code makes it any more maintainable, so maybe you can show it here.

    - Erwin
  68. You're forgetting something. Not everything is database-tied.

    I entirely agree with that. That's why I was talking of data centric applications. Not every application is data centric. But an application that isn't, probably has no great need for ORM either.
    You sprinkle your posts with words like "atrocity", when you describing perfectly normal Java code.

    Yes indeed, because I consider some of the things that have become commonplace in Java application designs to be utterly atrocious. It's not that this particular piece of code is more atrocious than normal. As I said, it's clean professional code, that nevertheless represents a design philosophy that I criticise.
    I don't see how inserting SQL statements through your Java code makes it any more maintainable, so maybe you can show it here

    I wasn't talking about where to put the SQL. There's absolutely no need to put SQL everywhere in the Java code. It could be put into a view for example, or in a configuration file of some sort, that is used by a DAO. There are many ways to do it. I'm not so much interested in where exactly it is placed within the system.

    I'm interested in the formal model that is the basis for the representation of this kind of business rule and of course I'm interested in the amount of code that needs to be written and maintained to create and change the rule. There's just too much noise in this kind of procedural code. What's expressed in the code, is basically a mathematical formula. I don't see why someone who maintains this formula should have to keep track of a sequence of possibly polimorphic algorithmic steps. Looping and branching. Multiple classes, objects "sending messages" to one another, etc. It's way too low-level for this purpose.

    Now don't get me wrong, I'm not saying that OO is always too low level. Some types of systems can be expressed very well using a notion of individual objects communicating with each other in time and space. Many things in the world work this way, and it is sensible to model them in this way. And if these systems need to store data, then it's completely rational to use an ORM tool, load it all into memory, have the objects do their stuff and store them back as transparantly as possible. I'm just arguing against modeling everything in this way.
  69. And if these systems need to store data, then it's completely rational to use an ORM tool, load it all into memory, have the objects do their stuff and store them back as transparantly as possible. I'm just arguing against modeling everything in this way.

    I hope you don't mind me commenting here. I agree with a lot of what you say, but I think you are expressing a myth about how ORMs work. Much of what is expressed using objects doesn't involve 'loading it all into memory'. For example, you can describe 'fetch groups' so that only fields relevant to the processing are retrieved. An object present in an expression may be only partly populated with data. Even then, much of the retrieval and storage is batched into just a few database accesses. Tracing the actual SQL produced by a section of code using a good ORM with transparent persistence can be very revealing.
  70. And if these systems need to store data, then it's completely rational to use an ORM tool, load it all into memory, have the objects do their stuff and store them back as transparantly as possible. I'm just arguing against modeling everything in this way.
    I hope you don't mind me commenting here. I agree with a lot of what you say, but I think you are expressing a myth about how ORMs work. Much of what is expressed using objects doesn't involve 'loading it all into memory'. For example, you can describe 'fetch groups' so that only fields relevant to the processing are retrieved. An object present in an expression may be only partly populated with data. Even then, much of the retrieval and storage is batched into just a few database accesses. Tracing the actual SQL produced by a section of code using a good ORM with transparent persistence can be very revealing.

    I'm glad that ORM tools apply advanced optimisation tequniques. But I mostly take issue with the logical model, not so much with the physical one.
  71. I wasn't talking about where to put the SQL. There's absolutely no need to put SQL everywhere in the Java code. It could be put into a view for example, or in a configuration file of some sort, that is used by a DAO. There are many ways to do it. I'm not so much interested in where exactly it is placed within the system.

    Spring provides an flexible, non-intrusive framework to solve this. It allows you to define a DAO and wire the implementation of your choice: whether this is a direct SQL queries or by using an ORM.

    -- Mark
  72. Spring rules[ Go to top ]

    Mark,
    "Spring provides an flexible, non-intrusive framework to solve this. It allows you to define a DAO and wire the implementation of your choice: whether this is a direct SQL queries or by using an ORM."
    +1

    And you can use Spring + iBATIS or Spring + Hibernate with both Java and .NET.

    Regards
    Rolf Tollerud
  73. Alexandder, I agree that those computations could be performed with a query, and Hibernate does not prevent this (you can use either the HQL or plain SQL to carry on the computation).
    As far as the discount is concerned, the policy cannot always implemented in SQL.

    For what concerns using rowsets and direct SQL for data oriented applications, I agree it's a nice idea as long as you can make sure the amount of business logic is near to zero and stays that way. In the past I've started applications this way, only to regret this becase happy clients kept on asking add-ons that required significant business logic...
    I also like the type safety, it's like a safety net... again, it's the result of past (bad) experiences when I was fresh out of the university.
    Maybe I should try again today, with more experience and more disclipline it should be less painful.
  74. For what concerns using rowsets and direct SQL for data oriented applications, I agree it's a nice idea as long as you can make sure the amount of business logic is near to zero and stays that way. In the past I've started applications this way, only to regret this becase happy clients kept on asking add-ons that required significant business logic...

    Is it "business logic" ? I see no business and no OOP in this code:

    private BigDecimal getFlightReservationsPrice() {
         BigDecimal totalPrice = new BigDecimal(0);
         Iterator rs = getFlightReservations().iterator();
         while (rs.hasNext()) {
             FlightReservation r = (FlightReservation) rs.next();
             totalPrice = totalPrice.add(r.getPrice());
         }
         return totalPrice;
     }
  75. Is this business logic?[ Go to top ]

    <quote>
    Is it "business logic" ? I see no business and no OOP in this code:

    private BigDecimal getFlightReservationsPrice() {
         BigDecimal totalPrice = new BigDecimal(0);
         Iterator rs = getFlightReservations().iterator();
         while (rs.hasNext()) {
             FlightReservation r = (FlightReservation) rs.next();
             totalPrice = totalPrice.add(r.getPrice());
         }
         return totalPrice;
    }
    </quote>

    yes, why not? You can add some rules inside this method:

    private BigDecimal getFlightReservationsPrice() {
         BigDecimal totalPrice = new BigDecimal(0);
         Iterator rs = getFlightReservations().iterator();
         while (rs.hasNext()) {
             FlightReservation r = (FlightReservation) rs.next();
             totalPrice = totalPrice.add(r.getPrice());
             // Check the totalPrice...
             if (totalPrice > 100) {
                  totalPrice = ...
             }

         }
         return totalPrice;
    }

    It depends on your "imagination" to see this method as a business logic...

    Cheers,
    Lofi.
  76. Is this business logic?[ Go to top ]

    Doe's is it become "business" after I move predicate from query to procedure in JAVA code ?
  77. Is this business logic?[ Go to top ]

    <quote>
    Doe's is it become "business" after I move predicate from query to procedure in JAVA code ?
    </quote>

    no, but the given method *is* a business logic of the application. It calculates the correct price for the application. Whether it is written in Java, SQL, Assembler, ABAP, what so ever you name it... the method is still a business logic... ;-)

    Cheers,
    Lofi.
  78. Is this business logic?[ Go to top ]

    I found it is more easy to see OutOfMemoryError than to imagine business logic in this OO and SQL free code.
  79. Is this business logic?[ Go to top ]

    I found it is more easy to see OutOfMemoryError than to imagine business logic in this OO and SQL free code.
    Please explain yourself. It is easy to make bold statements, especially one-liners without any explanation, but in this case, you are seriously wrong.
  80. Mumble... why not? It's the way the company computes the flight reservation price. Maybe a special discount for flight reservation is provided for people that travel to Manila, or that book a certain amount of travels, and so on.
    That fact that it could be expressed in SQL or it's simple does not mean it's not business logic.

    Besides this, I'm not implying that everything that's business logic should be coded in java instead of using SQL/HQL.

    What I said is that I experienced a couple of applications that seemed to be simple data oriented apps but ended up having lots of code, which ended up being in the DAO while I would preferred to put it in the object model, if only I have had one...
  81. Alexandder, I agree that those computations could be performed with a query, and Hibernate does not prevent this (you can use either the HQL or plain SQL to carry on the computation).

    No, hibernate doesn't prevent anything, and I never said that. I'm arguing against the use of procedural code where much less declarative code will achieve the same with much less code and in a much more maintainable way.
    As far as the discount is concerned, the policy cannot always implemented in SQL.

    Well it can in this case. And if it can be done in general depends on what prepocessing steps are taken. In my view, it is better to separate the question of accessing the data for price calulations from the rules governing the calculation itself. So, if for example various numbers that are needed for the calculation are in various subsystems or have to be acquired remotely from some third party, I would prefer to gather the data in one step and then have one or a few declarative statements that do the actual calculation. It's a matter of separating the mathematical (rule based) aspect from the communications and process aspects.
    For what concerns using rowsets and direct SQL for data oriented applications, I agree it's a nice idea as long as you can make sure the amount of business logic is near to zero and stays that way.

    My experience is completely different. I have seen a lot of hard coded business rules that could have been maintainable if represented in a properly normalized relational form instead of hard coded procedurally.
    In the past I've started applications this way, only to regret this becase happy clients kept on asking add-ons that required significant business logic...

    Don't be so vague :-) What kinds of business rules are you talking about? I think that there is a general lack of debate about the different kinds of business rules. There are business rules that concern processes and there are rules that concern data invariants and mathematical relationships and then there are various other more technical or operational rules. These different rules cannot always be treated in the same way.

    As I said, I think it is desirable to separate the question of how a set of base data is acquired from the representation that is then used as a basis for expressing declarative rules.
  82. Oh, another point about using the code for what could be accomplished by a query.

    The code you provide has probably been written in less than 5 minutes, with cut&paste from one method to the other.
    The author was certainly under pressure. He probably felt better writing the code than thinking about the query.

    What's wrong with that? If I'm in a hurry, and that happens, I just follow what seems the path of least resistance.

    Besides that, let's say this code is performance critical, and that for some reasons I know the objects are already in memory (maybe because the web page is a summary with all of the informations). Which code is faster, doing the computation like this, on the object I've already loaded, or doing three round trips to the database in order to gather the three totals?

    What I mean, the fact that this code could be expressed with a more concise query does not imply automatically that the query is better (I don't know about the context, in this particular case it could be better or not).
  83. Oh, another point about using the code for what could be accomplished by a query.The code you provide has probably been written in less than 5 minutes, with cut&amp;paste from one method to the other.The author was certainly under pressure. He probably felt better writing the code than thinking about the query.What's wrong with that? If I'm in a hurry, and that happens, I just follow what seems the path of least resistance.

    What you're basically saying is that the author of the code applied a quick and dirty method as a fallback because he didn't have the time to think about the query. I don't think this is the case. My impression is that the person who wrote this is a good and experienced developer, not somebody who doesn't care about his code. I don't believe it was laziness or time pressures. I rahter think it was a deliberate design decision and it was a very popular mainstream design decision. Not something for which the author of this particular code deserves to be criticised individually. It was not my intention to attack him personally. It was my intention to attack this design philosophy, which is certainly shared by many good developers.
    Besides that, let's say this code is performance critical, and that for some reasons I know the objects are already in memory (maybe because the web page is a summary with all of the informations). Which code is faster, doing the computation like this, on the object I've already loaded, or doing three round trips to the database in order to gather the three totals?

    First of all, I don't see how you would have 3 roundtrips to the database. What I see is that this can be done in a single SQL statement. There is a single roundtrip that returns a single number. But the more important question is if isn't a rather dangerous idea to represent a mathematical expression procedurally instead of declaratively for reasons of performance optimisation. There are ways of caching that don't affect the representational model. You can do caching inside the application server without rewriting a single declarative statement precedurally. And don't forget, that even if you do nothing in terms of caching, the DBMS will cache this in its own memory anyway, if it's use frequently. And if it's not used frequently, it shouldn't be cached at all.
    What I mean, the fact that this code could be expressed with a more concise query does not imply automatically that the query is better (I don't know about the context, in this particular case it could be better or not).

    My opinion is that something as volatile as a price calculation should be represented in the most high level way possible. Companies compete on price and the way it is calculated usually changes frequently. Ideally, it should be modifiable by sales managers. You don't want to hard code this in procedural Java code.

    But of course I am aware that this was not a production application and these requirements were probably not part of the coding contest. But then again, if someone just wanted to win the coding contest, he would've preferred the single SQL statement to the tenfold amount of Java code. I'm arguing that this would also have resulted in more maintainable code.

    The reason why this design was chosen, I'm quite sure, is a design philosophy that says, load everything into objects, forget about the database, process it procedurally, and store the results back into the database. The database is used as a kind of fancy file system, not as a place where knowledge is represented in a sound way in a model that is suitable for high level declarative set oriented processing.
  84. I'm arguing that this would also have resulted in more maintainable code.The reason why this design was chosen, I'm quite sure, is a design philosophy that says, load everything into objects, forget about the database, process it procedurally, and store the results back into the database. The database is used as a kind of fancy file system, not as a place where knowledge is represented in a sound way in a model that is suitable for high level declarative set oriented processing.

    I think that unless DB vendors ever get their act together and really work on true full-featured compatibility, this is, for better or worse, an inevitable development. ORMs are improving rapidly to the point where actions that are described procedurally with objects are batched and optimised into good SQL for the database. I totally agree that a more declarative way of processing is preferable, but I believe that will come with extensions to Java and languages that integrate with Java. Too many of us have learn the lessons of depending too much on one DB vendor and their extensions. Java is about freedom and portability.
  85. First of all, I don't see how you would have 3 roundtrips to the database. What I see is that this can be done in a single SQL statement. There is a single roundtrip that returns a single number.
    Ok, say we _had_ to bring all records from DB, to put them into a report which had a running total at the bottom, for example. I can't see how to bring all records plus the total in one single select statement, unless you add the total as the last column of the select, but this will increase network load and may make the query slower. If we already have all records in memory, it may be faster to iterate over all them and calculate the total in memory than doing another round-trip to the database just to fetch the total. Plus, doing the sum in memory will help increase concurrency in database, since you won't have to use transactions to surround both record fetching and total calculation queries.
  86. First of all, I don't see how you would have 3 roundtrips to the database. What I see is that this can be done in a single SQL statement. There is a single roundtrip that returns a single number.
    Ok, say we _had_ to bring all records from DB, to put them into a report which had a running total at the bottom, for example. I can't see how to bring all records plus the total in one single select statement, unless you add the total as the last column of the select, but this will increase network load and may make the query slower. If we already have all records in memory, it may be faster to iterate over all them and calculate the total in memory than doing another round-trip to the database just to fetch the total. Plus, doing the sum in memory will help increase concurrency in database, since you won't have to use transactions to surround both record fetching and total calculation queries.

    There are two separate issues you are talking about (or at least I think they should be kept separate). One is optimisation. Of course, if you already have all the data in memory, you can make the calculation without touching the database. However, if you need to fetch the data, for example because the in memory version might be stale, then the performance hit is all the greater, because lots of data have to be transmitted over the network needlessly and DBMS are largely IO bound nowadays. The two roundtrip story is actually not completely accurate. It depends a lot on how you code your JDBC and what particular capabilities the DBMS and the JDBC driver have. Usually, you should be able to fetch the sum and the records in a single roundtrip. You can even fetch multiple result sets in a single round trip. You could also cache the results of queries and transparently return them, provided you do the same query frequently. There's no shortage of caching ideas and there's no need to change the logical model of representation to do caching.

    But this whole issue of performance optimisation is actually not central and it's questionable to change the logical representation of rules and knowledge for optimisation purposes. You could as well argue that the whole calculation should be coded in JavaScript and run in the browser because that makes the application server and the DBMS scale better. Isn't it sensible to first think of the best way to logically express your rules and only afterwards think about how to optimise the processing of these rules?
  87. Isn't it sensible to first think of the best way to logically express your rules and only afterwards think about how to optimise the processing of these rules?

    Exactly my point! And if you're writing an application in the Java language, the most natural and logical way to express these rules, is in Java, not in the database or a database query language.
  88. Isn't it sensible to first think of the best way to logically express your rules and only afterwards think about how to optimise the processing of these rules?
    Exactly my point! And if you're writing an application in the Java language, the most natural and logical way to express these rules, is in Java, not in the database or a database query language.

    I think that's a pretty narrow view. I usually try to choose a formalism that fits the problem and allows me to understand and express the solution as concise as possible. For example, I wouldn't create an object model and write hundereds of lines of code to express what a one line regular expression does. Equally I'm not doing set processing by writing loops when can use a set oriented language.
  89. Yes, you keep coming up with great ideas, but you fail to provide an example of what this would look like.

    I'm sorry, but I'm getting an image here of an armchair architect. It is easy to toss around theories, but why don't you show us some examples? I'm pretty sure that they won't turn out to look so handy or easy in practice as in theory.
    For example, I wouldn't create an object model and write hundereds of lines of code to express what a one line regular expression does.
    I wouldn't either. Could you explain the context of this remark or is this a strawman argument?
    Equally I'm not doing set processing by writing loops when can use a set oriented language.
    But you're pretty good at ignoring all the responses you have got in this discussion. Java is not a set-oriented language. It doesn't make sense to complicate your architecture by introducing other languages when there isn't a single good reason to do so.
    Software engineering is usually done in teams, with less experienced people and more experienced people together, so you're not going to complicate matters when there is not reason to do so.

    If the application was full of such structures (which it isn't), maintainability may be the argument to change things, but you'd have to address all the drawbacks and issues that it would introduce.

    If the loops were over huge sets of data and the performance would suffer, than performance would be the argument. Yet we're talking about trips in a booking application. No trip is going to require more than, say, one hundred reservations, so performance isn't an issue here.

    Maybe it is time to admit that this wasn't a good example for the argument that you are trying to make.

    - Erwin
  90. Yes, you keep coming up with great ideas, but you fail to provide an example of what this would look like. I'm sorry, but I'm getting an image here of an armchair architect. It is easy to toss around theories, but why don't you show us some examples?

    Are you seriously asking me to post a SQL statement to prove that I am not an "armchair architect"? Come on, there's no need to get mad at me just because I disagree with your design decision.
    I'm pretty sure that they won't turn out to look so handy or easy in practice as in theory.

    The theory and practice of SQL is pretty well known. I'm completely happy with the SQL you posted. Put that in a view, call it from some DAO and you have a perfectly clean price calculation.
    For example, I wouldn't create an object model and write hundereds of lines of code to express what a one line regular expression does.
    I wouldn't either. Could you explain the context of this remark or is this a strawman argument?

    The context is that you said, in a Java project you want to use Java exclusively. Just as SQL is a language to express set operations on databases, a regular expression language is a language for expressing pattern matching operations on strings. I don't see why you refuse to use SQL when it makes your code more understandable, maintainable and shorter, but at the same time you agree that it's good idea to use regex for pattern matching.
    Equally I'm not doing set processing by writing loops when can use a set oriented language.
    But you're pretty good at ignoring all the responses you have got in this discussion.

    What in particular would that be?
    Java is not a set-oriented language. It doesn't make sense to complicate your architecture by introducing other languages when there isn't a single good reason to do so.

    Seems we're going in circles. I gave you a good reason for using SQL. The SQL that you have avoided by writing procedural code is about 20 times shorter than your code. It is more maintainable and less error prone because there is no need to think about variables, looping and branching, calling methods, multiple classes and so on. It is very close to the simple mathematical formula that you want to express.
    Software engineering is usually done in teams, with less experienced people and more experienced people together, so you're not going to complicate matters when there is not reason to do so.

    You're absolutely right. Matters should not be complicated, but that's exactly what you did by blindly following a classical OO approach where it was clearly misplaced.
    If the loops were over huge sets of data and the performance would suffer, than performance would be the argument. Yet we're talking about trips in a booking application. No trip is going to require more than, say, one hundred reservations, so performance isn't an issue here.

    I agree, performance is not the issue. The issue is code complexity and maintainability.
    Maybe it is time to admit that this wasn't a good example for the argument that you are trying to make

    I'm afraid I have to disappoint you there. It is, on the contrary, a perfect example for the anti-pattern I was talking about. Replacing a single SQL statement with 20 times as many lines of procedural looping and branching code, in a context where the problem itself is a mathematical operation over sets, is a bad idea.
  91. It is, on the contrary, a perfect example for the anti-pattern I was talking about. Replacing a single SQL statement with 20 times as many lines of procedural looping and branching code, in a context where the problem itself is a mathematical operation over sets, is a bad idea.

    Not always, I would say. This debate takes me back decades to when the APL computer language was much discussed. The APL users often expressed their amazement at why it was not so popular. They would state how almost any calculation could be expressed in terms of a few obscure math symbols and operators in APL. They could not see that that few developers understood the math involved.

    I think the same applies with SQL. The 'mathematical operation over sets' may be your preferred way of expressing the problem, but there are alternative ways to express it that are far more natural to others. Good OOP people will think in terms of how objects behave rather than how sets are manipulated. That is an equally valid way of looking at things, and I would even suggest that for those who have to audit and understand what goes on (managers and accountants) it is far clearer. In talking to an accountant, I doubt I would get very far if I talked about joins, unions or set operations! On the other hand, if I said 'for each customer, I get the invoice amount, multiply by the tax rate, and add to the running total' this would be understood. A procedural explanation is often what is needed.
  92. Leaving aside for moment the question of when to use an ORM tool try instead to look at code for products that really are suited for OOP, type Autocad programs (OOp's ancestral beginning), and behold you the elegance of true OOP.

    It is not only "database impedance" that breaks with OOP. Business programming as a whole is badly suited to OOP. You will begin to understand that when you compare with an environment where OOp really shines. This pretentious habit of making entities of database rows composed of a lot of getters and setters and called it "domain objects" is patetique. It reminds me of when the "soft sciences" adopt ways and approaches from the sciences like physics an chemistry - in a vain form of hubris they hope of that some status shall rub of..

    Business ORM users have no right to call themselves Object-Oriented programmers at all IMO. And please spare me expressions like "Good OOP people will think.."

    Regards
    Rolf Tollerud
  93. Leaving aside for moment the question of when to use an ORM tool try instead to look at code for products that really are suited for OOP, type Autocad programs (OOp's ancestral beginning)

    This is utter nonsense! I have used AutoCAD, supported AutoCAD users, and developed add-on software for AutoCAD, on and off for nearly 20 years. AutoCAD has nothing to do with OOP. It has simple lists of records (the items to be displayed) with attributes. This is clearly illustrated by the fact that the main language for AutoCAD development is plain LISP ('AutoLISP') - language with no OOP features at all.

    OOp's ancestral beginning was back in the 60s, at least with Simula (and probably earlier), then developed with Smalltalk in the 70s. C++ followed later.

    Saying AutoCAD is 'OOp's ancestral beginning' reveals a fundamental lack of understanding of the history and development of software engineering.
    Business programming as a whole is badly suited to OOP.

    Completely the reverse. Business programming is perfectly suited to OOP. The information we have to deal with - clients, invoices, stock etc. fit very nicely into object hierarchies (for example, trees of types of client) and we can effectively use polymorphism (work out income for all clients, no matter what class they are in).
    This pretentious habit of making entities of database rows composed of a lot of getters and setters and called it "domain objects" is patetique.

    It is merely mapping one way of describing data into another.
  94. J2EE makes me sick![ Go to top ]

    With "Autocad" I was meaning "vectorized drawing programs" in general. A vectorized drawing program is perfectly suited to OOP unlike "Business programs" that mostly are about presenting some data from the database different ways. Anyhow you know what pretentious is don't you? Pretentious, pretentious, pretentious. That is what it is, the whole J2EE world. Please note what I wrote above:

    "In all markets there are lots of low-cost solutions (predators) waiting for a mistake from the dominant player"

    The J2EE is responsible for so many mistakes that it boggles the mind. Please let us do the only merciful thing and bury the mess altogether.

    If we bury it tomorrow maybe there is still hope to recover from my state of disgust and abhorrence!

    Be merciful, I plead!

    Regards
    Rolf Tollerud
    (please!)
  95. J2EE makes me sick![ Go to top ]

    With "Autocad" I was meaning "vectorized drawing programs" in general.

    Which ones? Do you mean IntelliCAD? Intergraph? FastCAD? I have used them all. I know the file formats that they can handle. Not an object in sight. Sorry, but generalising does not help you here.

    The only drawing software I know of that really uses OOP is a Smalltalk application I wrote 12 years ago!
    A vectorized drawing program is perfectly suited to OOP unlike "Business programs" that mostly are about presenting some data from the database different ways.

    Actually, they aren't about that. Business programs are about 'business logic' - the processing of information. Information which belongs to a range of types and classes.
    Anyhow you know what pretentious is don't you? Pretentious, pretentious, pretentious. That is what it is, the whole J2EE world. Please note what I wrote above:"In all markets there are lots of low-cost solutions (predators) waiting for a mistake from the dominant player"The J2EE is responsible for so many mistakes that it boggles the mind. Please let us do the only merciful thing and bury the mess altogether. If we bury it tomorrow maybe there is still hope to recover from my state of disgust and abhorrence!Be merciful, I plead!RegardsRolf Tollerud(please!)

    I think this is a good place to end the discussion....
  96. Why are you here?[ Go to top ]

    I do not understand why you are here, if you are so disgusted?

    Why don't you just spend your time purposefully in any of the .Net support sites, educating and helping .Net users making it easy for those people.

    My only guess is you are a troll, you can not do any thing constructive.
  97. This is really hopeless.

    I am sorry you feel offended but what shall I say? After a long and bitter struggle where the die-hards never surrendered but fought to the last man we have finally defeated the EJB proponents. Only to experience that overuse of EJB is replaced with overuse of ORM?

    That is really hopeless. If we finally should succeed to hammer some sense into the head of the OO fanatics they will find themselves something new, like AOP or whatever.
    The J2EE people can simply not live without having something that elevates them above the common crowd in their perception.
    I feel like Sisyphus, endlessly rolling the rock to the top of the mountain only to see it falls back of its own weight.

    I suggest you read Alexander’s Jerusalem posts again, he has explained everything clear and perspicuously. But I guess he falls to the same prejudges and superstitions as others before him:

    "The too well-informed has nothing to offer others vanity, you realize that if you are sensible. That particularly appears to the woman, if she should happen to know anything" Jane Austen

    Stop being such a conservative bore, look into and play with Ruby On Rails and the D programming language. All is not going Microsoft’s way. I am sure they will not appreciate that D is taking the place of Mono/C# on Linux.

    Regards
    Rolf Tollerud
  98. Self-destroying post[ Go to top ]

    Amazing. You have actually managed to contradict yourself in the same post.

    combine:
    Only to experience that overuse of EJB is replaced with overuse of ORM?

    with:
    If we finally should succeed to hammer some sense into the head of the OO fanatics they will find themselves something new, like AOP or whatever.

    and with:
    Stop being such a conservative bore, look into and play with Ruby On Rails

    add something from the Ruby on Rails website:
    ActiveRecord ... It’s an implementation of the object-relational mapping (ORM) pattern

    and also a description of Ruby from that website:
    Ruby.. the Object Oriented Scripting Language

    And what do you get?

    "I don't like ORM. Avoid the OOP fanatics. Stop being a bore. Go and look at Ruby on Rails, that well-known OOP system with a built-in ORM."

    Awesome.
  99. I never said that ORM is always wrong. Whatever the merits of Ruby On Rails in serious context, it is at least the ultimate Quick and Dirty tool. And I am not against all OO neither, only overuse and fanatism.

    This dishonest way of arguing - to deliberate misinterpret to discredit your opponent is really unworthy of you.
    After all you better than Cameron! IMO.
  100. I never said that ORM is always wrong. Whatever the merits of Ruby On Rails in serious context, it is at least the ultimate Quick and Dirty tool.

    This is a change from what you have said. In the past you have argued that Ruby on Rails is ready for the production of serious projects (you quoted Basecamp).
    And I am not against all OO neither, only overuse and fanatism.This dishonest way of arguing - to deliberate misinterpret to discredit your opponent is really unworthy of you. After all you better than Cameron! IMO.

    I'm not misinterpreting; just trying to point out inconsistencies.

    To be honest, Rolf, I not sure you are a Troll as others have suggested. I think you may have an honestly held point of view and I would like to debate with you if this is the case. However, I do find it hard to find a consistent point of view in what you post. One minute RoR is a threat to J2EE, the next minute it is a 'Quick and Dirty' tool. One minute you are rubbishing J2EE, then next it's only some aspect of entity bean use. One minute its 'AutoCAD is where OOP started', the next its 'any vector drawing program' and so on. Such inconsistencies are fine if we admit to them and also admit when we are wrong (as I often am!).
  101. All is because you are mincing words; you are not trying to understand what is your opponents view really is. That is normal behavior when people fell threaded. There are no inconsistency anywhere of what I have said:

    1) "One minute RoR is a threat to J2EE, the next minute it is a 'Quick and Dirty' tool"

    At this time today RoR is a very useful 'Quick and Dirty' tool. Tomorrow who knows? If a Perl program can ashive 50 million page views a day with fastCGI then so can Ruby. Then we have the future possibility of compiling. I think that it is safe to say that dynamic languages will taka a big chunk out of J2EE some day. How big nobody knows.

    2) "One minute you are rubbishing J2EE, then next it's only some aspect of entity bean use"

    It is difficult to say what is J2EE. If you are using just a tiny-whiny whiff of J2EE do you then have a J2EE application? It is of course possible to use J2EE in an rational and intelligent way with Spring or as a replacement for Corba. But it is the attitude, the eager willingness to over-complicate even the tiniest project, the horrible pseudo-language, the longing for something "above ordinary common". It is to me thoroughly disgusting and things that are presented like that usually are Ptomkin deceptions in my experience. J2EE has acquired itself a rigid culture that is almost impossible to change. J2EE is normally used as the exact opposite to KISS.

    3)'AutoCAD is where OOP started', the next its 'any vector drawing program'. AutoCAD is a vector drawing program. And all those type of programs today make heavenly use of OO. IMO that is where OO shines most. "Draw yourself" ;)

    Regards
    Rolf Tollerud
  102. All is because you are mincing words; you are not trying to understand what is your opponents view really is. That is normal behavior when people fell threaded. There are no inconsistency anywhere of what I have said:1) "One minute RoR is a threat to J2EE, the next minute it is a 'Quick and Dirty' tool"At this time today RoR is a very useful 'Quick and Dirty' tool. Tomorrow who knows? If a Perl program can ashive 50 million page views a day with fastCGI then so can Ruby.

    There is no evidence that this can be done really reliably for complex sites. You presented a site as an example - but that site has had significant downtime.
    Then we have the future possibility of compiling. I think that it is safe to say that dynamic languages will taka a big chunk out of J2EE some day. How big nobody knows.

    Actually, this is something partly I agree with. But I don't think it will take a chunk out of J2EE. I think instead it will make server-side coding a far more dynamic and flexible exercise.
    2) "One minute you are rubbishing J2EE, then next it's only some aspect of entity bean use"It is difficult to say what is J2EE.

    On the contrary, J2EE is precisely defined.
    If you are using just a tiny-whiny whiff of J2EE do you then have a J2EE application?

    Yes, of course. In the same way as if you write even the smallest Java program you are still using Java.
    But it is the attitude, the eager willingness to over-complicate even the tiniest project, the horrible pseudo-language, the longing for something "above ordinary common". It is to me thoroughly disgusting and things that are presented like that usually are Ptomkin deceptions in my experience. J2EE has acquired itself a rigid culture that is almost impossible to change. J2EE is normally used as the exact opposite to KISS.

    This is where I think the debate is. You keep saying how you think J2EE is normally used. I don't think there is evidence for this. J2EE in all its richness is widely used because it is felt necessary. I think you are setting up a straw man here. If you could provide real evidence that J2EE was being used poorly in the way you suggest I would be interested. But so far, all the statements you have made (such as 'J2EE is not used in high performance sites') have been factually incorrect, and this has been easily demonstrated to be the case.
    3)'AutoCAD is where OOP started', the next its 'any vector drawing program'. AutoCAD is a vector drawing program. And all those type of programs today make heavenly use of OO. IMO that is where OO shines most. "Draw yourself" ;)RegardsRolf Tollerud

    That is one area when OOP would be very appropriate. However, it really isn't used like that in these programs. Saying they make use of OO is just plain wrong. If you have looked at the internals of how they store information (they publish this) it is clear that virtually no use of OOP is made. Have a look at the data formats for AutoCAD and see for yourself. Look at AutoLISP programming. Not one ounce of OOP.

    (What you may be thinking of is early GUI design, as in the Xerox Star and Smalltalk. These really were OOP.)

    Also, if 'object.DrawYourself' is appropriate, why not 'object.calculateYourTax'? The reason why OOP seems appropriate in the first case is because the same action 'drawing' is applied to a range of visual objects. In the same way, in business situations, OOP is appropriate because the same action 'calculate tax' can be applied to a range of taxable objects (invoices or receipts). OOP fits these things beautifully.

    Your view of where OOP is appropriate and not is about 25 years out of date - there was much debate in the early 80s about the extension of OOP beyond its use to represent 'nouns' (e.g. Windows and Widgets) to the representation of more abstract things and processes. I believe there were many good Byte articles about this.
  103. "Your view of where OOP is appropriate and not is about 25 years out of date"

    Very well then. Are you willing to take a challenge? I choose Adobe Illustrator as representative of a Modern vector based drawing program. It present itself like this:

    "Adobe Illustrator is the industry standard vector, or object oriented, drawing program

    Now let me see if I can find some examples of real OO programming for you (Shape abstract class and the seven classes that inherit it. Adding shapes to the container, ShapeFill class, events, GameStyle classes etc etc) which will make you feel like you are standing under the Niagara Waterfall*. OO in database-projects is nothing more that a pale, shallow copy of the real thing.

    Regards
    Rolf Tollerud
    * or like the poor souls that was victim to "the Total Perspective Vortex" machine in "The Hitch Hikers Guide to the Galaxy".
  104. why not just admit you were wrong?[ Go to top ]

    "Your view of where OOP is appropriate and not is about 25 years out of date"Very well then. Are you willing to take a challenge? I choose Adobe Illustrator as representative of a Modern vector based drawing program. It present itself like this: "Adobe Illustrator is the industry standard vector, or object oriented, drawing programNow let me see if I can find some examples of real OO programming for you (Shape abstract class and the seven classes that inherit it. Adding shapes to the container, ShapeFill class, events, GameStyle classes etc etc) which will make you feel like you are standing under the Niagara Waterfall*. OO in database-projects is nothing more that a pale, shallow copy of the real thing.RegardsRolf Tollerud* or like the poor souls that was victim to "the Total Perspective Vortex" machine in "The Hitch Hikers Guide to the Galaxy".

    Your challenge is to demonstrate how Adobe Illustrator in any way confirms the statement
    "AutoCAD is a vector drawing program. And all those type of programs today make heavenly use of OO".

    You said ALL make use of OO. They don't. You were wrong.
    Now let me see if I can find some examples of real OO programming for you (Shape abstract class and the seven classes that inherit it. Adding shapes to the container, ShapeFill class, events, GameStyle classes etc etc)

    Now let me find some examples of OO programming for you.
    'Stock' abstract class and those that inherit from it: LongLastingStock, ShortLifetimeStock (stock which has to be shipped soon after delivery). Adding stock items to a DeliveryNote class...

    Any example you give for visual classes I can match for financial classes.
  105. Also, if 'object.DrawYourself' is appropriate, why not 'object.calculateYourTax'?

    My own explanation is that encapsulation works well in the first case but not very well in the second. You can easily marry data and functions for short lived in memory objects, but you have an entirely different situation in business systems that rely on long lived data which is used by multiple applications and by multiple users at the same time for very different purposes. Real encapsulation is effectively impossible in such systems. Also, business data has a very differnt life cycle than the procedural code that acts on it.

    And because business data has such a long life span, you cannot determine all the access paths upfront. That is, you cannot define a reasonably useful API in which to encapsulate it. You have to represent it in a very generic way that allows future functionality to be built on top of it and access it in unforseen ways, using unforseen technologies and languages. All of this creates a very different situation from the one you have in the case of GUI widgets where data and functionality evolve in sync.

    For data centric business systems, separation of code and data is a necessity. For a windowing system or a flight simulator or a computer game or a graphics package, encapsulation is a desirable means for managing dependencies. These applications own their data, but business applications don't.
  106. Alexander,
    "For data centric business systems, separation of code and data is a necessity. For a windowing system or a flight simulator or a computer game or a graphics package, encapsulation is a desirable means for managing dependencies. These applications own their data, but business applications don't"

    Exactly! It is nothing wrong with your brain. Do you eat a lot of fish?

    Wonder and admiration is not enough to express your feelings when you see real OO programming in action.

    ORM! Allow me to laugh.

    Reards
    Rolf Tollerud
  107. ORM! Allow me to laugh.

    Another example of total lack of consistency.

    Earlier in this thread:
    Stop being such a conservative bore, look into and play with Ruby On Rails

    One minute you are promoting Ruby on Rails, which uses the ActiveRecord ORM, next you are saying ORM makes you laugh.

    Well, I tried to have a reasoned debate, but your inability to hold a single consistent idea over the period of a few posts makes this pointless.
  108. Steve,

    What you need to learn is called "sense of proportions". That is what the Oxford intellectuals call it. What does it mean?

    It means that something can appear greater than A but less than B. It all depends on what you compare with! Simple isn't it?

    Regards
    Rolf Tollerud
  109. Steve, What you need to learn is called "sense of proportions". That is what the Oxford intellectuals call it. What does it mean?It means that something can appear greater than A but less than B. It all depends on what you compare with! Simple isn't it?RegardsRolf Tollerud

    Let's put together some quotes from you:
    I can not see why a RoR project with "a mix of dual or quad processor servers, with lots of RAM and 64bit CPU supporting a cluster of databases", modern cache policy, stateless as far as possible could not scale equal to the largest Java projects?
    At this time today RoR is a very useful 'Quick and Dirty' tool.

    and finally...

    ORM! Allow me to laugh.

    So, you have moved from saying that ORM-based RoR could 'scale equal to the largest Java projects' to laughing at ORM.

    And I won't take lessons about a sense of proportion from someone who things Ebay is 'the most expensive project in IT history'....
  110. RoR is not bound to ORM forever[ Go to top ]

    You are confusing current time with coming times. if they sometime in the future put RoR on "a mix of dual or quad processor servers, with lots of RAM and 64bit CPU supporting a cluster of databases, etc etc" I am confident that they wont use ORM anymore.
  111. RoR not bound to ORM is not RoR[ Go to top ]

    You are confusing current time with coming times.

    I'm not confusing anything. Those quotes are from you.
    if they sometime in the future put RoR on "a mix of dual or quad processor servers, with lots of RAM and 64bit CPU supporting a cluster of databases, etc etc" I am confident that they wont use ORM anymore.

    Of course, if that is the case, it won't be RoR. Rails consists of three parts: ActiveRecord (the ORM), ActionPack and ActionMailer.

    So basically you are predicting that RoR will be used without ORM, making it .... not RoR!

    More inconsistency.

    This is not getting anywhere - I give up!
  112. Very well then, ponder this.

    with RoR 2 out of 3 of my objections against ORM disappear!

    Traditional ORM:

    1) Hundreds or even thousands of autogenerated pages with names of tables and columns hardcoded into the code. (ush!)

    2) Adding to or deleting columns break the code (detrimental for "Kaizen" - incremental improvements, very bad)

    3) Poor performance

    With Ruby on Rails only 3) is left which may or may not be important. After all we are only talking about a 20-30% decrease in performance.

    Regards
    Rolf Tollerud
  113. P.S.[ Go to top ]

    And you can still use handcoded SQL with AJAX!
  114. P.S.[ Go to top ]

    And you can still use handcoded SQL with AJAX!

    This is a very, very bad idea. The reason is that you will end up with hard-coded table and column names throughout your web pages, which are potentially cached away your machine! Think how tricky that is to maintain.
  115. Very well then, ponder this.with RoR 2 out of 3 of my objections against ORM disappear!

    Let's deal with these objections...
    1) Hundreds or even thousands of autogenerated pages with names of tables and columns hardcoded into the code. (ush!)

    This is false. With traditional ORM the names of tables and columns are absolutely not hard-coded into the code. There is a mapping layer (with JDO this is in the .jdo files). This is what gives ORM its portability - you can move between different database types (which may require different table names etc.) with no change at all in your source code - all that changes is names in the small mapping files.
    2) Adding to or deleting columns break the code (detrimental for "Kaizen" - incremental improvements, very bad)

    No it doesn't. Adding or deleting columns need little impact on the code - again because of the mapping layer. You can specify that newly added columns should be ignored, or you can use GUI tools that come with your ORM to automatically add these fields to your classes. If you delete columns, you can use refactoring tools in IDEs such as Eclipse or NetBeans to locate all uses of the corresponding instance variable, and deal with this as you wish.
    3) Poor performance

    This is not true. The query language statements and cacheing in an ORM can be finely tuned to give high performance. There is the usual example of EBay - they use such an ORM and get very high performance indeed. An ORM will usually have a second-level cache which will mean that reading of data can be extremely fast, even on clustered systems. In fact having ORM on a clustered system can be better than not having it, because the ORM product may include tools to deal with both read and write chacheing.

    In fact, points (1) and (2) apply not to ORM but to non-ORM with direct JDBC calls or embedded SQL, because there is no single point in the application (such as a .jdo file) where a changes in the schema can be isolated from changes in the code.

    The most important aspect of traditional ORM that prevents the problems you describe are is the mapping layer (.jdo files, .hbm files etc.). This protects the code from having to be continually modified to deal with minor changes in the schema. The flaw in Rails is that it does not have this mapping later, and classes that represent tables are generated dynamically at run time. For this reason Rails (or specifically ActiveRecord) does indeed suffer from the problems you describe. However, traditional ORM - JDO, Hibernate etc. doesn't.
  116. 1) "With traditional ORM the names of tables and columns are absolutely not hard-coded into the code. There is a mapping layer."

    But you still have the cluttering of hundreds or even thousands of autogenerated files.
    2) "You can use GUI tools that come with your ORM to automatically add these fields to your classes."

    Not good enough. With RoR the columns are added or deleted automatically. And what do you do with the handwritten modifications to the GUI? Doesn't regeneration destroy everything? That is what I like most with RoR, classes are generated dynamically at run time but manual changes in GUI are not touched. Ideally for the development in incremental improvments.
    3) "The query language statements and caching in an ORM can be finely tuned to give high performance"

    Let's not quarrel about performance. The little difference is not important and as far as I know most traditional ORM tools allow you to handcode SQL in case of emergency.

    No, the question for me is quite simple that it is not KISS. The only thing that is missing in RoR is a mapping layer that almost certainly will be there in the future.

    Don't you think that it will be fun to compare uptime/downtime of livejournal.com with TSS? :)

    Regards
    Rolf Tollerud
  117. 1) "With traditional ORM the names of tables and columns are absolutely not hard-coded into the code. There is a mapping layer."
    But you still have the cluttering of hundreds or even thousands of autogenerated files.

    No you don't. The only files you have are the mapping configuration files. There are only a few of these (perhaps only 2 in the case of JDO!).
    2) "You can use GUI tools that come with your ORM to automatically add these fields to your classes." Not good enough. With RoR the columns are added or deleted automatically.

    Yes, but that is the problem! The columns are only added and deleted in the classes which represent the tables, not in the rest of the code. For example, you may mention a column name in the view or controller layers. This bit of the code will not change when you amend the database. Your hand-written view code could easily break if you amend the database, and you can't easily pick this up before runtime as the mapping is only generated at runtime - this seems very fragile to me.
    And what do you do with the handwritten modifications to the GUI? Doesn't regeneration destroy everything?

    No. Refactoring tools handle all this cleanly. They can pick up (and change) references to fields in the view layer as well as in the model or controller. This is the advantage of great IDEs like Eclipse and Netbeans.
    That is what I like most with RoR, classes are generated dynamically at run time but manual changes in GUI are not touched. Ideally for the development in incremental improvments.
    3) "The query language statements and caching in an ORM can be finely tuned to give high performance"
    Let's not quarrel about performance. The little difference is not important and as far as I know

    Indeed. I agree.
    No, the question for me is quite simple that it is not KISS. The only thing that is missing in RoR is a mapping layer that almost certainly will be there in the future.

    If you are right, I would look at it again. This is my huge objection to RoR at the momement. I really doubt that they will put in this mapping layer, as one of the main boasts on the RoR site is how they avoid using configuration files. We shall see!
    However, Don't you think that it will be fun to compare uptime/downtime of livejournal.com with TSS? :) RegardsRolf Tollerud

    Since when has TSS been down continually for 2 says, like livejournal has? Also, LiveJournal does not handle streaming media. Also, LiveJournal is NOT RoR :)

    Rolf - we have had a decent discussion in the last few posts! Thanks!
  118. P.S.[ Go to top ]

    Besides, if you read the thread you will see that I advocates ORM for the "Quick and Dirty". For the moment, that is what Ruby on Rails is good for and ORM is totally appropriate. The future may show up a different scenario.
  119. Also, if 'object.DrawYourself' is appropriate, why not 'object.calculateYourTax'?
    My own explanation is that encapsulation works well in the first case but not very well in the second. You can easily marry data and functions for short lived in memory objects, but you have an entirely different situation in business systems that rely on long lived data which is used by multiple applications and by multiple users at the same time for very different purposes.

    I disagree - see below.
    Real encapsulation is effectively impossible in such systems. Also, business data has a very differnt life cycle than the procedural code that acts on it.

    I am not considering procedural code that acts on the data - I am talking about long-term stored objects that have behaviour. Then, the lifecycle of both the code and data is the same.
    And because business data has such a long life span, you cannot determine all the access paths upfront. That is, you cannot define a reasonably useful API in which to encapsulate it.

    In that case, you transform the objects to add new functionality. This is the extensibility allowed by OOP.
    For data centric business systems, separation of code and data is a necessity. For a windowing system or a flight simulator or a computer game or a graphics package, encapsulation is a desirable means for managing dependencies. These applications own their data, but business applications don't.

    All I can say is that I fundamentally disagree. All too often I see data separated from code, and as a result that data has lost its meaning, and there is little sense of what the constraints on the data are and how it is appropriate to process it.

    Even data stored in a relational system has code associated with it, as constraints, relationships, triggers etc.
  120. lets us get hold of facts[ Go to top ]

    "Perl program ashives 50 million page views a day, 1000 per second at peak, with fastCGI."

    Steve,
    "There is no evidence that this can be done really reliably for complex sites. You presented a site as an example - but that site has had significant downtime"
    And where are your proof or links to that docmentation?

    I put a watch* on the site in question precisly as I have done for TSS before. http://www.theserverside.com/news/thread.tss?thread_id=27498#131160

    The current uptime of TSS varies between 98-99%. That is not good enough. Soon we can compare it with livejournal.com with Perl/fastCGI!

    Regards
    Rolf Tollerud
    (*with the help of www.alertsite.com)
  121. Further comments on an extraordinary post..
    It reminds me of when the "soft sciences" adopt ways and approaches from the sciences like physics an chemistry - in a vain form of hubris they hope of that some status shall rub of..

    As someone who has (as part of a very varied career) been a scientist (theoretical chemist), I think you ought to be careful about your analogies.
    Business ORM users have no right to call themselves Object-Oriented programmers at all IMO. And please spare me expressions like "Good OOP people will think.."RegardsRolf Tollerud

    OOP is even more powerful than just being a tool for representing business objects. It allows clean extensions of business models. Inheritance and polymorphism allow new classes of client, suppler, stock etc. to be added, with new behaviour and properties, without any need to alter existing tested code. This is a significant advantage over relational systems where adding new attributes can require the modification existing records.
  122. Inheritance and polymorphism allow new classes of client, suppler, stock etc. to be added, with new behaviour and properties, without any need to alter existing tested code. This is a significant advantage over relational systems where adding new attributes can require the modification existing records.

    Polymorphism is nice and something similar can be expressed in an RDB as well, for example with unions, but I agree it easier using OO. Unfortunately mainstream OO languages like Java are pretty limited in their use of polymorphism. Why is a method call polymorphic only with regard to one particular parameter (this)? I never quite found this plausible. It can be worked around with the visitor pattern, but that makes the code increasingly mysterious and awkward the more "parameters" you add.

    But there's another OO shortcoming that annoys me more: The strict separation of static and dynamic aspects of objects when it comes to defining classes. For example, in natural language we often say things like: An adult is a person who is more than 18 years old. In a relational system I can express the class of adults on the same level as I can express person by saying something like:

    create view adult as
       select * from person where dob >= add_months(sysdate, -12 * 18)

    This view can be used like any other table for most purposes. In Java, I have to define classes statically and I have to assign objects explcitly to exactly one class and the class of an object never changes as long as it exists. A class like Adult wouldn't be very useful in Java.
  123. create view adult as&nbsp;&nbsp;&nbsp;select * from person where dob >= add_months(sysdate, -12 * 18)
    A class like Adult wouldn't be very useful in Java.

    Person.isAdult();

    What could be easier :))

    OK. This was a bad example. Try again. :)
  124. create view adult as&amp;nbsp;&amp;nbsp;&amp;nbsp;select * from person where dob >= add_months(sysdate, -12 * 18)A class like Adult wouldn't be very useful in Java.
    Person.isAdult();What could be easier :))OK. This was a bad example. Try again. :)

    No, it was a very good example. Your code shows exactly what I meant. If you read read my post carefully, you will see that I was talking of defining classes. Your code does not define a class. In Java it is not possible to define a class of things based on dynamic conditions. You can of course check dynamic conditions and act upon them, but you cannot say everything that satisfies this condition is part of this or that class.

    A relational view can be used in the same way as a relational table (for many purposes). You can apply set operations to them no matter if they are tables or views. This makes the conceptual model very simple and flexible because every result of a set operation again has the same structural properties as the source of the operation.
  125. No, it was a very good example. Your code shows exactly what I meant. If you read read my post carefully, you will see that I was talking of defining classes. Your code does not define a class. In Java it is not possible to define a class of things based on dynamic conditions. You can of course check dynamic conditions and act upon them, but you cannot say everything that satisfies this condition is part of this or that class.A relational view can be used in the same way as a relational table (for many purposes). You can apply set operations to them no matter if they are tables or views. This makes the conceptual model very simple and flexible because every result of a set operation again has the same structural properties as the source of the operation.

    You are trying to talk about "objects" using a "relational" approach. There lies your problem.

    A view is a view... A class is a class. One is used for representing a given set of data after being filtered by some criterion. The other is a way for representing a particular especification (abstraction)of an entity. By using the help of simple OO principles, you will realize that ADULT is not a class: It can't be. PERSON may be a class and this class may have some attribute called AGE which can be used for determining if a PERSON is ADULT,CHILD,NEW BORN,PENSIONER,Etc. It does not compare at all with the definition of a view.

    Interestingly enough, your comments and arguments are very similar to the ones found here: http://www.geocities.com/tablizer/oopbad.htm

    ... I am sure the author of the above mentioned website is a funny guy. Unfortunately, His reasoning (like yours too) is very flawed when it comes to talk about OO.

    Nice attempt from your side but you are talking about ORANGES when what you have in hand are just GRAPES.

    Cheers!
  126. Great link![ Go to top ]

    It's like Rolf, except semi-cogent.

    You should have also linked to the "why Java sucks" article:

    http://www.geocities.com/tablizer/javacrit.htm

    I enjoyed reading some of those rants there.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  127. AlertSite
    The Web Site Monitoring Company
    Daily Monitoring Summary

    Customer: Rolf Tollerud
    From: 2005-04-30 12:00:00
    Through: 2005-05-01 11:59:59
    Timezone: GMT +1:00 Report Help
             
    Site: www.livejournal.com/
    Primary Location:
    San Diego
    %Available:
    100.00
    Avarge Response Time:
    0.2702
    Warnings;
    0
  128. Rolf. Please read
    http://www.livejournal.com/powerloss/

    "approaching 24 hours of downtime... *sigh* We're still at it."

    You can show 100% uptime for any system if you pick a time period in which it has not been down! What matters is the long term, obviously.
  129. Perl suffer powerloss![ Go to top ]

    What have power loss to do with the reliability of dynamic languages and MySQL?

    The system guys at livejournal.com are managing very well to be beginners. Maybe they are past the initial problems now? We’ll see.

    TSS is nor past their initial problems after 5 years!

    Regards
    Rolf Tollerud
  130. Perl suffer powerloss![ Go to top ]

    What have power loss to do with the reliability of dynamic languages and MySQL?The system guys at livejournal.com are managing very well to be beginners.

    Because of the problems involved in recovering the system after the power came back on.
    Maybe they are past the initial problems now?

    What 'initial problems'? LiveJournal has been active since 1999.
    TSS is nor past their initial problems after 5 years!RegardsRolf Tollerud

    Please provide evidence of more than 24 hours downtime of TSS, equivalent to that of LiveJournal.
  131. Why don't you put a watch on TSS then? I can not do it because I used up my "free trial".
  132. Why don't you put a watch on TSS then? I can not do it because I used up my "free trial".

    I will. Also, you have said

    "TSS is down 3-4 hours in the week, day out day in".

    I assume you have evidence for this statement, and aren't just making it up. Please provide this evidence.
  133. 1) For the first I have monitored TSS before,
    http://www.theserverside.com/news/thread.tss?thread_id=27341#130488

    2) For the second I experience more problem that you because TSS is mostly down on the night, especially on the weekends. In fact when I logon on Monday morning at eight or nine it are more often down than up. At that time it is still middle of the night in US.

    3) For the third you can easily monitor TSS yourself with the free trial month at Alertsite.

    4) For the forth why do you not ask TSS? Dion Almaer is the Chief Architect of TSS and being British he will not have any squirmy excuses!

    Regards
    Rolf Tollerud
  134. P.S.[ Go to top ]

    Did you follow my link? Did you notice that Cameron claims in July 17, 2004 that Tomcat is 30x slower than WebLogic?

    Regards
    Rolf Tollerud
    (hi hi)
  135. P.S.[ Go to top ]

    Did you follow my link? Did you notice that Cameron claims in July 17, 2004 that Tomcat is 30x slower than WebLogic? RegardsRolf Tollerud(hi hi)

    I did follow your link, and he did not say that. He said (assuming he does not mind me quoting and highlighting):
    "Tomcat has definitely improved in its performance, but in load tests it used to be over 30x slower than WebLogic"

    I assume you understand the difference between "is" and "used to be"?
  136. RE:Squirmy excuses[ Go to top ]

    "I did ask you to provide evidence that this site was as poor in terms of uptime as livejournal, so please provide evidence that TSS has been down at any time for a 24 hour period."

    I do not say that TSS has been down for 24 hour (but I think it has!), but having a uptime of only 97-98% is worse that a single event of 24 hours down IMO!

    "Tomcat has definitely improved in its performance, but in load tests it used to be over 30x slower than WebLogic"

    Well, based on information so far we can definitely conclude that you and Cameron are not from old England.

    Regards
    Rolf Tollerud
    (For example, to open this thread takes over 1 minute and that has been the same all day..)
  137. RE:Squirmy excuses[ Go to top ]

    "I did ask you to provide evidence that this site was as poor in terms of uptime as livejournal, so please provide evidence that TSS has been down at any time for a 24 hour period." I do not say that TSS has been down for 24 hour (but I think it has!), but having a uptime of only 97-98% is worse that a single event of 24 hours down IMO!

    Actually, it isn't. If you are waiting for information (I use livejournal, and often use it to arrange social events with friends) an occasional downtime of 24 hours (especially unplanned) is FAR worse than the odd hour or two.
    "Tomcat has definitely improved in its performance, but in load tests it used to be over 30x slower than WebLogic"

    Exactly. 'used to be', not 'is'. Just as I said.
    Well, based on information so far we can definitely conclude that you and Cameron are not from old England.

    Although I can't see the relevance, I am certainly English.
    For example, to open this thread takes over 1 minute and that has been the same all day..)

    You need to have a talk with your ISP. It takes 15 seconds here, and that has been consistent.
  138. RE:Squirmy excuses[ Go to top ]

    Well, based on information so far we can definitely conclude that you and Cameron are not from old England.RegardsRolf Tollerud(For example, to open this thread takes over 1 minute and that has been the same all day..)

    I've been following this thread. It takes between 10 and 15 seconds for this thread to open.

    Don't blame TSS because your ISP, corporate, or home network sucks.
  139. I have 8Mbit ADSL[ Go to top ]

    Non other site in US that I browse has problem. Even 15 seconds is disaster in IMO.
  140. I have 8Mbit ADSL[ Go to top ]

    Non other site in US that I browse has problem. Even 15 seconds is disaster in IMO.

    Sure. Look, you are the only one complaining. TSS doesn't come up any slower than any other site I view.

    If it is too slow for you, don't use it.
  141. I have 8Mbit ADSL[ Go to top ]

    Non other site in US that I browse has problem. Even 15 seconds is disaster in IMO.

    What problem? That was on my low-bandwidth ADSL home system. On a system with faster (> 100 MBit) network access it only takes 3-4 seconds. Considering that there is more than 500k of HTML alone, and there are a considerable number of pieces to the page (images etc.), that is very fast.
  142. RE:Squirmy excuses[ Go to top ]

    For example, to open this thread takes over 1 minute and that has been the same all day..

    FALSE. At least for me, it just takes 10 seconds.
  143. 7 seconds to open the TSS main page
    31 seconds to open "My threads"
    8 seconds to open this thread

    (Some other sites)

    http://www.theonion.com/index.php?pre=1
    3 seconds

    http://slashdot.org/
    3 seconds

    http://www.livejournal.com/
    3 seconds

    http://english.aljazeera.net/HomePage
    2 second

    http://www.yahoo.com/
    1 second

    http://www.microsoft.com/
    1 second

    Futhermore the whole TSS site was down from 8.52 (Greenwich meantime) and at least two hours.

    Regards
    Rolf Tollerud
  144. Rolf,

    Isn't this negativity just a bit over the top, even for you? You are being completely consumed by your irrational hatred. So this the mark of your much-touted "classical education"?

    TSS has definitely had outages lately, and it is definitely running more slowly than usual. First they had some severe database outages, some lasting for hours at a time. Then they throttled the database access to avoid killing it, and the result is a general slow-down for operations that hit the db.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  145. This to me looks like he's running out of excuses to blame Java, J2EE, EJB and Java community. TSS is out? No matter if database is out, blame Java. And .com burst too, BTW. Reminds me of South Park cartoon movie, when they sang that "Blame Canada" tune, but much funnier! :)
  146. Reminds me of South Park cartoon movie, when they sang that "Blame Canada" tune, but much funnier! :)

    Oh dear. Don't get me started again. I have only just recovered from laughing at Rolf's: "Even 15 seconds is disaster". Along with 'Ebay is the most expensive IT project ever' and 'AutoCAD is where OOP started', this should be added to the list of some of the craziest things ever posted on an IT forum.
  147. Don't forget "J2EE probably the main cause to the 2000-2003 recession " too! :)
  148. 1) Cameron’s perfectly aquedate and reasonable explanation to the problem.

    2) Henrique, Steve, Star Trooper, David, etc vehemently claims that "there is no problem".

    Regards
    Rolf Tollerud
  149. AlertSite
    Daily Monitoring Summary
             
    Site: www.livejournal.com/
    Primary Location:
    San Diego

    %Available:
    100.00

    Avarge Response Time:
    1.2485

    Warnings:
    0
  150. Where have I said there is no problem? Actually, after TSS migration to Tapestry + JDO I have felt its stability have decreased, but I will not start singing "Blame Java" before knowing what the the problem really is, as it could be tons of different reasons, like database, operational system, network, ISP, J2EE, EJB, Entity Beans, Java community, ORM tools, elephants, wasted billions, impractical scientists, IT recession or whatever makes you feel better at the end of the day. ;) Well, at least I can tell their problems are not worse than a 24 hrs outage.
  151. "as it could be tons of different reasons, like database, operational system, network"

    Yes but I wouldn't have started this uptime/downtime thing if not someone had ranted that livejournal.com has serious available problems due to Perl and/MySQL. That is ridiculous as securing the site is fairly routine these days and has to with backup and failover systems and things like that that is ordinary engineer work and has nothing to do with programming tools.

    If you were honest you would admit that I am neither the extremist like those at
     
    http://www.geocities.com/tablizer/javacrit.htm,

    neither do I share the opinions of the average TSS member. I just want the truth.

    To find out which one have the best availability, livejournal.com or TSS is fairly easy business so be careful with your predictions. Notice that I have not made any predictions! :) (but I will be surpriced if TSS win).

    Twelve 2 hours downtimes is similar to one 24 hours outage IMO.

    Regards
    Rolf Tollerud
  152. I am not an extremist![ Go to top ]

    if not someone had ranted that livejournal.com has serious available problems due to Perl and/MySQL. That is ridiculous as securing the site is fairly routine these days and has to with backup and failover systems and things like that that is ordinary engineer work and has nothing to do with programming tools.

    Actually, I didn't. I did nothing more than point out that the site had had serious downtime. You mentioned the site as an example of a good site with high performance and high uptime. I simply proved that this claim was nonsense.

    Anyway, you mentioned PERL. You were bizarrely using a PERL site as an example of why RoR is good. Go figure!
    Twelve 2 hours downtimes is similar to one 24 hours outage IMO.

    I already pointed out that this is wrong. LiveJournal is a social site. If you were arranging a social event with someone using a blog and the site went down, then 2 hours downtime is hugely better than 24 hours.
  153. 4 May 2005

    The daily report from Alertsite so far has not reported any downtime for livejournal.com.

    On the other hand - what are the TSS crew doing? The problems from yesterday are still not solved in spite of more than 24 hours passing. The site was down 23.54 yesterday and today 06.29 GMT it took 1 min and 21 second to open "My Threads"

    Regards
    Rolf Tollerud
  154. this is beginning to look serious[ Go to top ]

    it took 1 min and 21 second to open "My Threads"RegardsRolf Tollerud
    But yet, you still return. Maybe they are trying to make you want to go away? :)
  155. Thank you for your kind empathy. If it wasn't for you I don't know what I should think.

    But if it wasn't for me you will not know what to think either!

    Regards
    Rolf Tollerud
    (I should charge a fee)
  156. Thank you for your kind empathy. If it wasn't for you I don't know what I should think.But if it wasn't for me you will not know what to think either!RegardsRolf Tollerud(I should charge a fee)
    Are you hiring out the multiple voices in your head?

    I really hope you aren't really trying to help us think because of the time it is difficult to figure out what you are trying to say.
  157. We should encourage him[ Go to top ]

    Thank you for your kind empathy. If it wasn't for you I don't know what I should think.But if it wasn't for me you will not know what to think either!RegardsRolf Tollerud(I should charge a fee)
    Are you hiring out the multiple voices in your head?I really hope you aren't really trying to help us think because of the time it is difficult to figure out what you are trying to say.

    I think this is rather harsh! We should encourage Rolf. After all, as most of the links he provides contradict the opinions he puts forward, he is providing us with an expanding resource of information to counteract anti-Java propoganda.
  158. Pardon me[ Go to top ]

    I am not in the business of propaganda but into anti-propaganda.
    Report for the third day
     
    AlertSite
    Daily Monitoring Summary
             
    Site: www.livejournal.com/
    Primary Location:
    San Diego

    %Available:
    100.00

    Avarge Response Time:
    1.2297

    Warnings:
    0
    And anti-FUD.

    Regards
    Rolf Tollerud
  159. We should encourage him[ Go to top ]

    Thank you for your kind empathy. If it wasn't for you I don't know what I should think.But if it wasn't for me you will not know what to think either!RegardsRolf Tollerud(I should charge a fee)
    Are you hiring out the multiple voices in your head?I really hope you aren't really trying to help us think because of the time it is difficult to figure out what you are trying to say.
    I think this is rather harsh! We should encourage Rolf. After all, as most of the links he provides contradict the opinions he puts forward, he is providing us with an expanding resource of information to counteract anti-Java propoganda.

    Sorry that the truth hurts. I was somewhat joking, but humor plays close to the big hot fire of truth. Providing half truths is one thing, but saying we can't think without him is another.
  160. excellent news[ Go to top ]

    I am happy to report that now with the new Google Accelerator and with TSS solved their problems the speed today is (5 May 2005 07.08 GMT),

    Open TSS: 3 seconds
    "My threads": 5 seconds!
    this thread: 4 seconds

    absolutly amazing!

    Regards
    Rolf Tollerud
  161. We should encourage him[ Go to top ]

    Sorry that the truth hurts. I was somewhat joking, but humor plays close to the big hot fire of truth. Providing half truths is one thing, but saying we can't think without him is another.

    Sorry - I was attempting humour. I don't think you are being harsh at all.
  162. we will all be rich[ Go to top ]

    Steve & Mark!

    Watching each of you trying to communicate with each other gives me an idea.

    TSS.net is offering a reward for comical material. Here are ample possibilities we should not let pass by IMO. Just be yourself and I will be your manager!

    I am sure we can agree upon how to share the profit.

    Regards
    Rolf Tollerud
    (I could use a little money right now)
  163. we will all be rich[ Go to top ]

    Steve &amp; Mark!Watching each of you trying to communicate with each other gives me an idea.TSS.net is offering a reward for comical material. Here are ample possibilities we should not let pass by IMO. Just be yourself and I will be your manager!I am sure we can agree upon how to share the profit.RegardsRolf Tollerud(I could use a little money right now)
    I highly agree with Rolf's idea: I'd love to have an on-line version of Dilbert. ;)
  164. we will all be rich[ Go to top ]

    Steve &amp; Mark!Watching each of you trying to communicate with each other gives me an idea.
    At least we were communicating.
    Just be yourself and I will be your manager
    Those who can communicate, do. Those who can't - manage those who can. :)

    Steve,
     You are right about Rolf. :)
  165. We should encourage him[ Go to top ]

    Sorry that the truth hurts. I was somewhat joking, but humor plays close to the big hot fire of truth. Providing half truths is one thing, but saying we can't think without him is another.
    Sorry - I was attempting humour. I don't think you are being harsh at all.
    Guess it was the English in both of us. ;) (I am only 1/4 English. But I am also 1/4 Dutch so I am cheap, er, frugale too)
  166. well what have we now?[ Go to top ]

    1) Cameron’s perfectly aquedate and reasonable explanation to the problem.2) Henrique, Steve, Star Trooper, David, etc vehemently claims that "there is no problem". RegardsRolf Tollerud
    I've troubleshoot problems with F-16s, C-141s aircraft and Satellite communications equipment in addition to other computer hardware and software problems. As you've shown and as was discussed in the past, your problem resolution (troubleshooting skills) leave much to be desired.
  167. 1) For the first I have monitored TSS before,http://www.theserverside.com/news/thread.tss?thread_id=27341#130488

    Sorry, but noting the performance over a couple of weeks last year does not consitute evidence for 'TSS is down 3-4 hours in the week, day out day in'. I'm not saying you are wrong, just that one sample then does not show a continuous problem.
    2) For the second I experience more problem that you because TSS is mostly down on the night, especially on the weekends.
     In fact when I logon on Monday morning at eight or nine it are more often down than up. At that time it is still middle of the night in US.

    Evidence? I often watch TSS through the night and don't have problems. It is certainly not 'more often down that up' on monday mornings.
    3) For the third you can easily monitor TSS yourself with the free trial month at Alertsite.

    I will.
    4) For the forth why do you not ask TSS? Dion Almaer is the Chief Architect of TSS and being British he will not have any squirmy excuses! RegardsRolf Tollerud

    Because he is not making any statements about uptime. You are. If you make a statement, I would expect evidence from you.

    I did ask you to provide evidence that this site was as poor in terms of uptime as livejournal, so please provide evidence that TSS has been down at any time for a 24 hour period.
  168. Surely one day of uptime proves that it is 100% reliable. This is pretty low, even for you Rolf.
  169. Please Tero,

    I am just getting started. I will monitor for one month at least!

    Bear with me. The last 2-3 days I will publish the username and password to Alertcite so anyone can verify.

    Regards
    Rolf Tollerud
    (TSS downtime for that last two weeks has been terrible)
  170. create view adult as&amp;nbsp;&amp;nbsp;&amp;nbsp;select * from person where dob >= add_months(sysdate, -12 * 18)A class like Adult wouldn't be very useful in Java.
    Person.isAdult();What could be easier :))OK. This was a bad example. Try again. :)

    To clarify this further, the equivalent of my view definition in Java would have to look something like this:

    class Adult extends Person [where getAge() > 18];

    And then you would be able to write a method in some other classe with a signature like this:

    public void signContract(Adult a){...}

    This is not possible in Java for a good reason. It would be completely inconsistent because Java has static type checking and such a type can never be checked statically. In my view the type systems of most OO languages are severely limited when you compare it with various other models.
  171. To clarify this further, the equivalent of my view definition in Java would have to look something like this:
    class Adult extends Person [where getAge() > 18];

    And then you would be able to write a method in some other classe with a signature like this:public void signContract(Adult a){...}

    This is interesting. Could to explain in more detail? Do you mean you want a object to be conditionally a member of a class? What is the advantage - I mean in order to pass an object to the 'signContract' method would you already have to know if it was an instance of 'Adult'? In that case, wouldn't you have to have already run some kind of query? If not, isn't "a instanceof Adult" equivalent to "((Person) a).getAge() > 18"?
  172. To clarify this further, the equivalent of my view definition in Java would have to look something like this:class Adult extends Person [where getAge() > 18];And then you would be able to write a method in some other classe with a signature like this:public void signContract(Adult a){...}
    This is interesting. Could to explain in more detail? Do you mean you want a object to be conditionally a member of a class? What is the advantage - I mean in order to pass an object to the 'signContract' method would you already have to know if it was an instance of 'Adult'? In that case, wouldn't you have to have already run some kind of query? If not, isn't "a instanceof Adult" equivalent to "((Person) a).getAge() > 18"?

    Yes it is equivalent in the sense that it has the same runtime effects. There are two advantages however: First, if an object can belong to a class based on dynamic state, this class can be used (almost) everywhere a static class could be used, like in the signature of a method. So you could say:

    void signContract(Adult a){...}

    instead of

    void signContract(Person p){
       if (p.getAge() < 18)
          throw new SorryWrongTypeOfPersonException();
       ...
    }

    The first form is preferable because the signature, which is part of the public interface, declaratively expresses the preconditions for calling the method, whereas in the second form, the check has to be written procedurally and it is part of the implementation. signContract(Person p) in a way lies about what you can do. It says, you can pass a Person here, and when you try it says sorry, not that kind of Person.

    One remedy would be to write a class like this:

    class Adult extends Person {

       Person inner;

       public Adult(Person p){
          if (p.getAge() < 18)
             throw ...
          inner = p;
       }
    }

    and then you simply call signContract like this:

    Person myPerson ...
    signContract(new Adult(myPerson));

    A similar result could be achieved by using the state pattern. But the problem with this is that it's a lot of work. You have to make sure that as soon as the age changes (and it does all the time), the object is somehow removed from the class or cannot be treated as a member of the class anymore. The state pattern does that. But it's a lot of rather obscure code for something that should really be part of the type system. And it's only a simulation. The object doesn't really change its class, rather you have multiple objects posing as one, which can lead to problems where object identity is important.

    Of course all of this is not such a big problem as long as you don't make your objects persistent. Long living objects are much more likely to change their class than short lived in memory objects. And that's one more reason why I think OO is not well suited for many data centric applications. But again, I'm not saying that it cannot be done in an OO language. Everything can be done in any Turing complete language. It's just a question of how clearly and to the point a particular logical idea can be expressed in a particular model.
  173. signContract(Person p) in a way lies about what you can do. It says, you can pass a Person here, and when you try it says sorry, not that kind of Person.

    I think I am almost at the point of understanding! If I am right about what you are trying to express, I would say that from the point of view of an OOP developer, it is the wrong way around. It is anti-polymorphic. Instead of

    signContract(Adult p)

    it should be:

    class Person {

    public void signContract() throws CantSignContractException {
    if (age < 18) throw new CantSignContractException;
    ....
    }
    }

    The knowledge of age and behaviour should be within the Person class (and subclasses), and not in the enclosing code.

    I would suggest that expressing it your way is rather like having a conditional on the class - it is an implicit 'instanceof' test.

    Surely it is far better to have

    try {
    p.signContract()
    } catch (CantSignContractException e) {

    because you can, at some future date, add a new class (say 'AdultWhoCantSign') based on additional criteria encapsulated in the class, with no changes needed in the calling code; which is the beauty of polymorphism.
  174. I think I am almost at the point of understanding! If I am right about what you are trying to express, I would say that from the point of view of an OOP developer, it is the wrong way around. It is anti-polymorphic. Instead of signContract(Adult p)it should be:class Person {public void signContract() throws CantSignContractException {if (age < 18) throw new CantSignContractException;....}}The knowledge of age and behaviour should be within the Person class (and subclasses), and not in the enclosing code.

    I would say that depends on the particular application domain. What the rules for a Person to sign a contract are is not inherently a property of Person. It might be a property of some legal system or it might depend on the type of contract and so on. But I don't think this has much to do with the question of if you can create classes based on dynamic properties. What you seem to be concerned with here is what the right design for a particular domain is. It might well be:

    LegalSystem ls = ...
    Contract c = ...
    Person p = ... //or Adult a = ...

    ls.signContract(c, p);
    or
    c.sign(ls, p);
    or
    p.signContract(c, ls);

    Which shows another problem with Java's lack of multimethods, because the obvious thing would be to just say signContract(c, ls, p) and dispatch that call according to the types of _all_ parameters.
    I would suggest that expressing it your way is rather like having a conditional on the class - it is an implicit 'instanceof' test. Surely it is far better to have try {p.signContract()} catch (CantSignContractException e) {because you can, at some future date, add a new class (say 'AdultWhoCantSign') based on additional criteria encapsulated in the class, with no changes needed in the calling code; which is the beauty of polymorphism.

    I disagree, because that violates the substitution principle which is fundamental to polymorphism. To define a class Person and state that a Person can sign a contract and then disallow it for a particular subtype of Person, is in my view something that should be avoided (if at all possible). If you know at design time, that only certain types of Persons can sign contracts, then you should be able to express this fact in the type system.

    And I think this problem is well known because there are attempts at solving it declaratively. For example Eiffel's pre- and postconditions are just that, only that they don't express it in terms of classes. But they do express it as part of the formal signature, not as a surprise behaviour of the implementation.
  175. If you know at design time, that only certain types of Persons can sign contracts, then you should be able to express this fact in the type system.And I think this problem is well known because there are attempts at solving it declaratively. For example Eiffel's pre- and postconditions are just that, only that they don't express it in terms of classes. But they do express it as part of the formal signature, not as a surprise behaviour of the implementation.

    I did wonder when Eiffel would be mentioned :) The discussion seemed to have that kind of direction!

    I see what you are saying. I am not sure that I would not prefer:

    Person p;
    if (p.canSignContract()) {
    p.signContract();
    }

    But I sense you are after a more declarative approach!

    Thanks for the discussion - you have given me a lot to think about.
  176. <quoteblock>The two roundtrip story is actually not completely accurate. It depends a lot on how you code your JDBC and what particular capabilities the DBMS and the JDBC driver have. Usually, you should be able to fetch the sum and the records in a single roundtrip. You can even fetch multiple result sets in a single round trip. You could also cache the results of queries and transparently return them, provided you do the same query frequently. There's no shortage of caching ideas and there's no need to change the logical model of representation to do caching.</quoteblock>
    And is any of these options simpler to implement than doing a 10-line loop summing procedure over the fetched records? Most of them, IMO, requires some deep technical knowledge over specific database features, making it much more complex than the loop code.
  177. The two roundtrip story is actually not completely accurate. It depends a lot on how you code your JDBC and what particular capabilities the DBMS and the JDBC driver have. Usually, you should be able to fetch the sum and the records in a single roundtrip. You can even fetch multiple result sets in a single round trip. You could also cache the results of queries and transparently return them, provided you do the same query frequently. There's no shortage of caching ideas and there's no need to change the logical model of representation to do caching.
    And is any of these options simpler to implement than doing a 10-line loop summing procedure over the fetched records?
    How did you get to 10 lines? There are about 50 lines of price calculation code in Trip.java alone, and this code uses three other classes (I haven't looked at those) and then there is the hibernate mapping code you have to write.

    But this is not just about lines of code. It's also the complexity of the code that is caused by its procedural nature. You have to keep track of variables and follow the flow of control through quite a few classes and methods if you need to debug or maintain it. And this unspeakable BigDecimal mess (which is of course not the developer's fault) makes it all utterly unreadable.
    Most of them, IMO, requires some deep technical knowledge over specific database features, making it much more complex than the loop code.

    I would say, you need very little knowledge to submit a SQL statement and you can reuse that knowledge by putting it into some helper class. You could even use Hibernate to submit your SQL. But you're right if you're saying that database programming and SQL are not trivial if you make use of some more sophisticated features. It's always a question of learning effort versus productivity gains.
  178. Hundereds of lines of code (including Java source, configurations and mapping code) were written just so that lots of data can be loaded from the database over the network into the application process with the sole aim of looping over three different sets and doing calculations of the most ugly kind (see applyDiscount), and all this to replace a single SQL statement.

    No offense, but this reminds me of the days when somebody complained "how come it takes so many lines of code to print "Hello, World!" in Java?!"

    Besides, how would you do <em>exactly</em> what those hundreds of lines do in <em>one single</em> SQL statement?
    (I never liked the code-generation approach either anyway, so I do agree that part of the code is messy, but that's not the point here)
  179. Next Time Try Tapestry[ Go to top ]

    I've been very happy with Tapestry, Spring, and Hibernate running on Tomcat with MySQL.

    Tapestry, IMHO, is a better UI solution that JSP's...by far.

    BTW, TheServerSide.com is implemented in Tapestry.
  180. Missing Out!![ Go to top ]

    Note: Relational databases are written in languages like Java, C, C++ and not the other way around. Relational databases consists of up to millions of lines of Java/C++ code for rich functionality like declaritive indexing, declaritive control of the data access path, caching, replication, set operations, bulk inserts/updates, and all of this implemented in a layer directly above the filesystem for optimum performance.
    OK, this doesn't prove anything, but I think chances are that if you are going to write code in Java/C++ that you could instead have written in SQL, you are going to have to do more work or miss out on lots of crucial functionality already given to you by the relational database!!
    I think that many, if not most Java developers that use ORM, use it in order not to have to touch SQL. It should be the other way around...
  181. Mark van H wrote in an e-mail discussion:
    Could somebody some me this wonderfully elegant SQL statement that does all the trip calculations in one query? My bet is that it is horrible to read and uses oracle specific functions.

    Sure.
    That would be something along the lines of:

    SELECT
       (SELECT sum(price) FROM flight_reservations WHERE trip_id = ?),
       (SELECT sum(price) FROM car_reservations WHERE trip_id = ?),
       (SELECT sum(price) FROM hotel_reservations WHERE trip_id = ?)
    FROM dual

    and even:

    SELECT
       (
       ((100 - flight_discount_percentage) / 100 * (SELECT sum(price) FROM flight_reservations WHERE trip_id = ?)) +
       ((100 - car_discount_percentage) / 100 * (SELECT sum(price) FROM car_reservations WHERE trip_id = ?)) +
       ((100 - hotel_discount_percentage) / 100 * (SELECT sum(price) FROM hotel_reservations WHERE trip_id = ?))
       )
    FROM trip
    WHERE id = ?

    It's not a nice query but it isn't bad either. It doesn't help however. The problems are:

    1 * how do you fit this kind of query in the architecture
    2 * what if you change the object model and want to do calculations without writing the model back to the database first

    Point 1 can be solved with Hibernate itself; you can perform a calculation in SQL before setting a property with the javabean. It does mean that the queries will always be executed when loading the Trip, even when the data is not of interest, which is most of the time.
    Point 2 can't be solved that easily. You'll have to write checks to see if the data was modified after loading it from the database, use the value from the SQL query if it wasn't, or the java calculation if it was.

    It all depends on the requirements which solution you'll choose.
    SQL queries don't get refactored when you change your java code, are not typesafe, and when performed over small datasets are slower or need a lot of thought and experimentation to be done faster than plain Java code.

    Not using the features of the database when it would make implementing your requirements easier is a bad thing, but using the database for the sake of the database is just as bad.

    - Erwin
  182. SQL queries don't get refactored when you change your java code

    Refactoring is an altogether different business anyway, when you're talking about a database with existing data. There's limits to what you can refactor in the same sense you can refactor Java code, no matter where you put your SQL.
    , are not typesafe

    That's true, unless you put them into a view or a stored procedure or use a preprocessor like SQL/J.
    Not using the features of the database when it would make implementing your requirements easier is a bad thing, but using the database for the sake of the database is just as bad.

    Well, who could argue with that? But do you really think you have honored this rule in the case of the price calulation we're talking about?
  183. As editor in chief of the magazine that organized this RAD Race (as well as
    several earlier RAD Races) I think it might be good to add a couple of
    lines. Firstly: let it be clear that Vincent Partington and Erwin Bolwidt
    (and Spring et cetera) did a very good job. The difference in productivity
    between them and the winner was about 10%, whereas most Java teams of the
    past would have been very glad if only they would have reached 10% of the
    productivity of the winner. A couple of 4GL teams were less productive than
    Vincent and Erwin, so the claim ‘just as productive as 4GL’s’ is no
    hyperbole, at least not in the context of this race.
    I don’t agree with them where it comes to the comparison between Java and
    .Net. The .Net team did not use any frameworks at all. Besides that this
    team was not very experienced in writing new applications, their daily work
    is makes small changes to an existing application.
    Then: I would not underestimate the importance of the race. Even the teams
    that are not very successful agree on the fact that the race is very much
    like writing an application in the real world, the only difference is that
    you only have two days to do the job. One of the difficulties in the
    assignment lies in the fact that at an unknown moment you will have to cope
    with a change of requirements e.g.. Jury members like Ron Tolido - Vice
    president en Chief Technology Officer of Capgemini for Northern Europe and
    Asia and Rick van der Lans - highly regarded consultant, author and
    Lecturer (also chairman of the jury and author of the assignment) – take it very seriously. All this means: the Java community should
    be proud of the fact that a Java team did so well while competing with 4GL’s
    and MDA-tools. As for the comparison with .Net I would be very glad to see a
    better equipped team join the next race.
  184. why not use Velocity to render UI[ Go to top ]

    In my experience, Velocity is a much better alternatives to JSP.

    Developing Velocity page is faster than JSP for quick modify/check cycle.

    In my opinion, Velocity should be improved to allow for more controllable macro definition's visibility.
  185. Throwaway prototyping[ Go to top ]

    Hi,

    this is a very long thread and I havent managed to read everything.

    But let me say congratulations/feliciteerd to both Vincent and Erwin!

    I have noted some contentious arguments in this thread about how relevent and realistic this contest was and whether it could actually be practically applied in the workplace. This has been argued on both quality of the application, design and comparison to 4GL.

    At the very least, even the most sceptical, disapproving contributors must agree that this exercise proves that following:
    - java and j2ee frameworks (which are FREE) can be used effectively for quick throwaway prototyping.

    If it took these guys just 2 days to drum up this application, think how useful it could be used for prototyping and confirming user requirements/testing technology etc.

    Not only that, for a tech team weighted in java, they need not be 'distracted' by using a high level 4GL tool. They can stick to the java domain. Other advantages are:
    - software is free
    - hands on quantitative/qualitative feedback on the java implementation technology itself
    - sourcecode and architecture in the same format as the final implementation


    Larry
  186. Try this instead: http://mentawai.lohis.com.br/

    Small, Simple, Flexible and Easy XML-free MVC web framework.

    :-)
  187. XML isn't boring[ Go to top ]

    Try this instead: http://mentawai.lohis.com.br/Small, Simple, Flexible and Easy XML-free MVC web framework.:-)

    XML may be boring, but it is used for a reason. It can be easily validated, managed and transformed. Replacing mapping of actions in XML with mapping of actions in Java code does not make things easier - it makes things less flexible and less maintainable. The mapping of actions to actual pages should not be hard-coded into Java source, or if it is, is should be done as annotations.