Hibernate says it can call stored procedures in it's documentation. I've never done it though.
Shawn -----Original Message----- From: Vu, Thai [mailto:[EMAIL PROTECTED] Sent: Friday, February 10, 2006 5:05 PM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: With a new project, what technologies should I use? Wow, an answer from a prof. :) Sorry that I didn't give any information about the project I want to do. Your question showed that I missed a lot of things. - I am a sole developer building a 3MB source code application in a reasonable amount of time period (don't laugh at me please :) ). - The look and feel is not very important (i.e. some simple CSS and displaytag are fine). - As I am the only developer, I have to do everything from database, business logics to GUI. - I don't expect to use any prepared sql statement. I prefer using Hibernate or iBATIS. I think I will use iBATIS because iBATIS can call stored procedures (Hibernate cannot do that, can it?) because I can write stored procedures, triggers quite well (not well enough to build an application just using PL/SQL). - The site will contain a lot of dynamic elements and will not be updated often (updating is needed if a new functionality is required). - The business people are still figuring out what they want and I hope I do not have to build everything from scratch when they need a new feature. So, what is your advice with those information? Thanks for your answers. Sincerely. PS: By the way, what does PHB stand for in ` To a PHB, every application is a nail.'? -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Friday, February 10, 2006 3:17 PM To: Struts Users Mailing List Subject: Re: With a new project, what technologies should I use? On 2/10/06, Vu, Thai <[EMAIL PROTECTED]> wrote: >. Now what should I use if I > have to write a new web application? And correct me if I'm wrong > anywhere please. It's a little bit like asking a building contractor: "What materials should I use to build a new structure?" Just to pose a few rhetoric questions: Are you a sole developer building a five page application next week, or leading a team of ten developers building a five hundred application over the next year or two? Is the primary purpose of the application database access or something else? How important is look and feel? Are the java developers doing the markup, or is there a second team of HTML designers? Are you expected to use prepared statements, code your own SQL, or have it generated? Will the site be static or have a number of dynamic elements? How soon before the site needs to be updated (if ever)? Are the requirement stable, or are the business people still figuring out what they want? Will the site need to maintained and extended as business needs change, or would you start from scratch with a new site? Now some vendors want you to believe that no matter how you answer any of these questions, and a hundred more, there is only one true answer: Whatever product they want to sell you! One size fits all is a myth. We don't have a unified theory of relativity, and we don't have a unified framework for web development at all scales. Some things work better for small applications (Quantum). Somethings work better for larger application (Relativity). There is a tipping point when you need to shift gears from quick-and-easy to extensible-and-robust. It's one thing to build a bike-shed; it's another to build a skyscraper. A professional chooses the right tool for the job. To a PHB, every application is a nail. My best advice is to pick the smallest possible part of your application and try that part with a couple of likely technologies. Then, choose the one that best suits the application, your team, and you. If it is not worth the trouble of doing even a small part more than once, then the job is probably a small enough job that you can snag Java Studio Enterprise and do it with JSF out of the box. * http://developers.sun.com/prodtech/javatools/jsenterprise/reference/tech art/whatis.html HTH, Ted. http://husted.com/blog/ted/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] **************************************************************************** This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. **************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
