Anyone here have an insterest in a Spring Best Practices Project? I was thinking it would be great to have a sample webapp that used Spring for config, JDBC and MVC. It would only have one domain object and allow users to add, edit, delete and list. Thats all. No alternative way to do things. It would be as simple and straightforward as possible and still function. Every method and xml entry would be commented. It would also deal with the best way to manage xml config files as well as source code directory structure, naming conventions, transfer objects etc.
I know some of that is not directly Spring related but I think it would be great to have a standard way of doing things that the vast majority of webapps need to do. Any thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd be interested in helping out with this. I've already got something in place as a sample app for the Spring Live book. Actually, there's two apps - one is a baseline starter app for Hibernate+Spring+Struts development and then I have CVS snapshots of a Hibernate+Spring+Struts app and a pure Hibernate+Spring app. As I add more, there will be versions with JDBC, JDO and iBATIS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems reasonable as long as you're careful to leave the words 'best' or 'standard' completely out of it.
Spring provides choices, that's a good thing. Effectively telling someone that JSP is 'better' than Velocity or FreeMarker, or that Hibernate is 'standard' and JDBC or iBatis are not is (IMHO) a bad thing. Would someone working in a company with lots of JDO expertise be motivated to look seriously at Spring if we were giving out this sort of message? Probably less so than they might otherwise have been.
An app without those kind of choices built in would be useful - but make it clear that this is "one choice of many" in designing this type of application :-)
Just my $0.02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I totally agree. Choices are a good thing. I was thinking a 'best practices' example using Spring for config,JDBC and MVC. Then a 'best practices sample' using Spring config,MVC and Hibernate for persistance etc,etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Matt. The way I would like to do it is create the all Spring version first. Then have another version that does everything exactly like the first but uses, for instance, Hibernate instead of Spring JDBC but no other differences. If all the samples were based on EXACTLY the same functionality it would be much easier to understand the framework as a whole. The Spring samples we currently have all do completely different things AND in different ways. Can be confusing for the beginner.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That makes sense Bob. I think the hard part will be managing the different "versions". I use CVS branches to manage my baseline app, the struts version and the spring version and it's kindof a pain. I probably just don't know enough about CVS to do it efficiently. I've heard subversion makes this easier. I can setup a subversion server if necessary. I've applied for a java.net project for the baseline app - hopefully that'll be approved soon.
I should have an "all-spring" version of my app done in the next week or two. Maybe we could start with that as our baseline. The only thing I'm hesitant to remove is SiteMesh - it's not part of Spring, but it makes it soooo easy to decorate a site and make it look good. I know that Spring has themes, but the documentation doesn't exist for them - and I also think SiteMesh is probably the best "decoration framework" out there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If we have so many files that they are hard to keep up with maybe we are doing something wrong ;)
But seriously this brings up a important issue. Can we seperate out the Sping JDBC from the Hibernate code better? One idea that comes to mind is to have all the persistance config information in its own xml config file. See? Its a possible best practice already ;)
Maybe we could have one person in charge of each version. When the group as a whole decides what the best practice will be the owner of each version can implement it. Just a thought.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have a look at the Petclinic sample app: It allows to switch between Hibernate and JDBC data access layers by a simple change in the contextConfigLocation in web.xml.
As of Spring 1.1 RC1 (already in CVS), Petclinic adds an OJB data access implementation. So you can switch between 3 data access strategies, on the very same data model!
Might be worth having a look at before starting your own best practices sample with exchangeable data access layers :-)
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In article [http://www.xml.com/pub/a/2004/08/11/rest.html]
the author, Hao He, created a list that may be applicable to this topic. Except for the last item, these seem like good things that should be noted in docs and so forth.
Thus, I would make the list:
BP: best practice
G: general guideline
PS: proposed informal standard
TIP: implementation tip
AP: anti-pattern
J. Betancourt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anyone here have an insterest in a Spring Best Practices Project? I was thinking it would be great to have a sample webapp that used Spring for config, JDBC and MVC. It would only have one domain object and allow users to add, edit, delete and list. Thats all. No alternative way to do things. It would be as simple and straightforward as possible and still function. Every method and xml entry would be commented. It would also deal with the best way to manage xml config files as well as source code directory structure, naming conventions, transfer objects etc.
I know some of that is not directly Spring related but I think it would be great to have a standard way of doing things that the vast majority of webapps need to do. Any thoughts?
I'd be interested in helping out with this. I've already got something in place as a sample app for the Spring Live book. Actually, there's two apps - one is a baseline starter app for Hibernate+Spring+Struts development and then I have CVS snapshots of a Hibernate+Spring+Struts app and a pure Hibernate+Spring app. As I add more, there will be versions with JDBC, JDO and iBATIS.
Seems reasonable as long as you're careful to leave the words 'best' or 'standard' completely out of it.
Spring provides choices, that's a good thing. Effectively telling someone that JSP is 'better' than Velocity or FreeMarker, or that Hibernate is 'standard' and JDBC or iBatis are not is (IMHO) a bad thing. Would someone working in a company with lots of JDO expertise be motivated to look seriously at Spring if we were giving out this sort of message? Probably less so than they might otherwise have been.
An app without those kind of choices built in would be useful - but make it clear that this is "one choice of many" in designing this type of application :-)
Just my $0.02
I totally agree. Choices are a good thing. I was thinking a 'best practices' example using Spring for config,JDBC and MVC. Then a 'best practices sample' using Spring config,MVC and Hibernate for persistance etc,etc.
Thanks Matt. The way I would like to do it is create the all Spring version first. Then have another version that does everything exactly like the first but uses, for instance, Hibernate instead of Spring JDBC but no other differences. If all the samples were based on EXACTLY the same functionality it would be much easier to understand the framework as a whole. The Spring samples we currently have all do completely different things AND in different ways. Can be confusing for the beginner.
That makes sense Bob. I think the hard part will be managing the different "versions". I use CVS branches to manage my baseline app, the struts version and the spring version and it's kindof a pain. I probably just don't know enough about CVS to do it efficiently. I've heard subversion makes this easier. I can setup a subversion server if necessary. I've applied for a java.net project for the baseline app - hopefully that'll be approved soon.
I should have an "all-spring" version of my app done in the next week or two. Maybe we could start with that as our baseline. The only thing I'm hesitant to remove is SiteMesh - it's not part of Spring, but it makes it soooo easy to decorate a site and make it look good. I know that Spring has themes, but the documentation doesn't exist for them - and I also think SiteMesh is probably the best "decoration framework" out there.
If we have so many files that they are hard to keep up with maybe we are doing something wrong ;)
But seriously this brings up a important issue. Can we seperate out the Sping JDBC from the Hibernate code better? One idea that comes to mind is to have all the persistance config information in its own xml config file. See? Its a possible best practice already ;)
Maybe we could have one person in charge of each version. When the group as a whole decides what the best practice will be the owner of each version can implement it. Just a thought.
Have a look at the Petclinic sample app: It allows to switch between Hibernate and JDBC data access layers by a simple change in the contextConfigLocation in web.xml.
As of Spring 1.1 RC1 (already in CVS), Petclinic adds an OJB data access implementation. So you can switch between 3 data access strategies, on the very same data model!
Might be worth having a look at before starting your own best practices sample with exchangeable data access layers :-)
Juergen
To expand the categories a little.
In article [http://www.xml.com/pub/a/2004/08/11/rest.html]
the author, Hao He, created a list that may be applicable to this topic. Except for the last item, these seem like good things that should be noted in docs and so forth.
Thus, I would make the list:
BP: best practice
G: general guideline
PS: proposed informal standard
TIP: implementation tip
AP: anti-pattern
J. Betancourt
What does REST xml stuff have to do with SPRING best practices?
REST xml stuff has nothing to do with discussion.
I was specifically referring to the bulleted list.
Seems a very good way to categorize what the intent of a "best practice" project should deliver.
Good thing I didn't find the list on a page about something even less relevant like European Jazz or how to do the dolphin kick. :)
J. Betancourt