> I usually code against DAOs configured in Spring. GORMs main advantage IMO > is the uncluttered and quickly readable configuration of the domain classes > and relations. The dynamic finders are definitely helpful for smaller scale > admin type apps and for quick testing. For more complex apps there is > usually no way to avoid a dedicated business/service layer or at least > complex DAOs.
Of course if you take only GORM part out of Grails that is all you get DAO that is simple to use. Grails however has services that are could and should be used to do the access (never mind the controllers filled with DA code - although it demonstrates the possibility no sane person, I hope, would do it for a production ready application) > Using Hibernate sessions directly in the page-code is IMO also more a thing > of prototyping and proof of concept. Especially if you don't know in advance > if there will be a change of data-access technology in the future, e.g. to > TopLink, Ibatis or maybe even to an object database like db4o. In these > cases GORM is of course no help either as long as it's tightly tied to > Hibernate. GORM itself is not tied to Hibernate (except maybe for queries which are HQL and H stands for Hibernate). The problem there is that the only implementation provided is done with Hibernate and probably will be for at least a while. And that kind of sucks and I think Grails team knows about it :-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
