|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 186
Messages: 186
Messages: 186
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Opinion: Java with Spring just as productive as a 4GL RAD tool
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 PointsWe 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.
ObstaclesThe 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.
ConclusionJava 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?
|
|
|
Message #168141
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Java with Spring just as productive as a 4GL RAD tool"
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 ?
|
|
|
Message #168148
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Choice of words
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
|
|
|
Message #168149
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Java with Spring just as productive as a 4GL RAD tool
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?
|
|
|
Message #168161
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Java with Spring just as productive as a 4GL RAD tool
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'.
|
|
|
Message #168168
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OpenSessionInView filter
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
|
|
|
Message #168170
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring as "killer app" for J2EE development
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
|
|
|
Message #168171
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: no hibernate sessions in JSPs!
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
|
|
|
Message #168173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: no hibernate sessions in JSPs!
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
|
|
|
Message #168213
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring Rules
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
|
|
|
Message #168214
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
offcourse teh comparison is debatable but...
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
|
|
|
Message #168216
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring+ORM Rules
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.
|
|
|
Message #168218
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
P.S.
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
|
|
|
Message #168224
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
P.S.
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).
|
|
|
Message #168232
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168233
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Well, it is Rolf
Brother, don't expect Rolf to be serious.
I am a hopeless optimist, I guess.
|
|
|
Message #168239
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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!
|
|
|
Message #168240
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168251
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Well, it is Rolf (!)
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
|
|
|
Message #168252
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168255
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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
|
|
|
Message #168256
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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
|
|
|
Message #168259
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168263
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Well, it is Rolf (!)
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.
|
|
|
Message #168267
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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;
}
|
|
|
Message #168269
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is this business logic?
<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.
|
|
|
Message #168270
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168271
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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...
|
|
|
Message #168272
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is this business logic?
Doe's is it become "business" after I move predicate from query to procedure in JAVA code ?
|
|
|
Message #168274
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Next Time Try Tapestry
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.
|
|
|
Message #168280
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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).
|
|
|
Message #168281
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is this business logic?
<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.
|
|
|
Message #168291
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ruby on Rails would have won easely
"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.
|
|
|
Message #168294
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168295
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168300
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Castor
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
|
|
|
Message #168304
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is this business logic?
I found it is more easy to see OutOfMemoryError than to imagine business logic in this OO and SQL free code.
|
|
|
Message #168305
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168307
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168308
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
feeling a little chilly these days?
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
|
|
|
Message #168309
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168310
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
feeling a little chilly these days?
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.
|
|
|
Message #168312
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168318
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What relevance has this?
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?
|
|
|
Message #168353
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please allow us one (1) gram of intelligence
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
|
|
|
Message #168358
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
When was I questioning intelligence
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?
|
|
|
Message #168361
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is this business logic?
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.
|
|
|
Message #168362
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ok, go on selling your snake-oil then
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.
|
|
|
Message #168363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168364
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Please explain the relevance
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.
|
|
|
Message #168368
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ok, go on selling your snake-oil then
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.
|
|
|
Message #168373
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
with enough money you can do anything
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.
|
|
|
Message #168375
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
P.S.
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.
|
|
|
Message #168377
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
with enough money you can do anything
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.
|
|
|
Message #168382
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ok, go on selling your snake-oil then
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.
|
|
|
Message #168385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
two schools of OO
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.
|
|
|
Message #168389
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Alone in the cold
Hehe Rolf,
I'm glad you waste so much time posting meaningless comments here - means you're writing less code.
|
|
|
Message #168402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Home-grown ORM==still another case Of OMU (ORM Misuse)
”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
|
|
|
Message #168403
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Home-grown ORM==still another case Of OMU (ORM Misuse)
It just do not exist a case ... Say what you want about Rolf but he knows his english. This is not Rolf.
|
|
|
Message #168409
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing Out!!
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...
|
|
|
Message #168415
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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".
|
|
|
Message #168422
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168423
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168425
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168430
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168438
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It all started with ORM
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.
|
|
|
Message #168440
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
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.
|
|
|
Message #168441
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Home-grown ORM==still another case Of OMU (ORM Misuse)
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.
|
|
|
Message #168449
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168453
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
feeling a little chilly these days?
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.
|
|
|
Message #168458
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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
|
|
|
Message #168460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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. :) 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. 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).
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!). :)
|
|
|
Message #168465
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168466
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: put your money where you mouth is.
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
|
|
|
Message #168473
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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?
|
|
|
Message #168476
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168480
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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
|
|
|
Message #168484
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Java with Spring just as productive as a 4GL RAD tool
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.
|
|
|
Message #168485
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: put your money where you mouth is.
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?
|
|
|
Message #168486
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168488
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168493
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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
|
|
|
Message #168494
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring rules
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
|
|
|
Message #168527
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168529
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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)
|
|
|
Message #168532
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168534
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
<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.
|
|
|
Message #168548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Productivity is not just a matter of tools and frameworks
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.
|
|
|
Message #168549
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please stop to calling yourselves OOP programmers, you are not
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
|
|
|
Message #168555
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rolf, please talk about things you understand
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.
|
|
|
Message #168565
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please stop to calling yourselves OOP programmers, you are not
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.
|
|
|
Message #168568
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE makes me sick!
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!)
|
|
|
Message #168572
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE makes me sick!
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....
|
|
|
Message #168579
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why are you here?
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.
|
|
|
Message #168582
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please stop to calling yourselves OOP programmers, you are not
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.
|
|
|
Message #168583
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please stop to calling yourselves OOP programmers, you are not
create view adult as 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. :)
|
|
|
Message #168588
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
why not use Velocity to render UI
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.
|
|
|
Message #168594
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
so I can not do any thing constructive, moi?
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 | |
