Need for Spring "Framework Pattern Templates"

[benethridge]

Hi, everyone.

I'm starting this thread, after reading over the interesting thread:

Book: "Domain driven design" implemented in Spring

http://forum.springframework.org/showthread.php?t=19429

I think that we are missing something fundamental in the Spring releases, and in the software development world, in general. I'll call them "Framework Pattern Templates". If someone else has already coined that term AND these already exist for Spring, please clue me in, and the rest of this is moot:

So we can conculde that it is just hard work making good software!

I agree. Let's see if we can make it a little easier. Read on...

I think we are in need of more professionel people sharing there experience, people who have seen projects fail or succeed for certian reasons... that informations should be gathered on a site that keeps track of these things and give us good discussions ... so that when we start a new project we can learn from other peoples mistakes instead of reinventing the wheel and making the same mistake. Actually I expected more feedback from the Spring guru's on these forums. Or are tehy in the dark when we are talking about there anemic model approach ... because I think that is one of the Spring weaknesses for now.Grtz

Kind of to your point, after 6+ years of java web development, it difficult to produce any kind of industrial-strength web app, without, almost every year it seems, going through yet another huge "framework" learning curve, with all it's wheel-reinventing and "mistakes".

There are just SO many different opinions and design approaches on this. I mean just look at all the different opinions on that one thread! And the essential problem is this: If you pick one design pattern over the other and implement, you won't know until production time, or at least deep in the middle of coding it all, whether the opinion/pattern you picked was a winner!

What seems, to me, to be the critical missing piece, is what I'll call a "framework pattern template".

"Framework patterns" would be analogous to the well-documented GoF patterns, except that they would be specific to the "framework", in this case, Spring. For all I know, they may already exist, and I just haven't spotted them yet in my readings. Do they?

In any case, a "framework pattern template" would be an ACTUAL RUNNABLE App (like, say, the Echo sample app I recently contributed for Spring, or the Pet Clinic sample, or the Spring Web Service Airline sample, and so on).

Notice, please, that everyone now calls these "samples", which is CLOSE to a "framework pattern template", but is not one yet. If Spring adds a "framework pattern description" for, say, a "Simple Spring JAXB Web Service", the Echo sample could then be stated as the "framework pattern template" for it. If Spring adds a framework pattern description for, say, "Spring Web Service With Hibernate-Fronted Database", the Airline sample could be the framework pattern template for that (if I'm remembering the Airline sample details correctly). The number and granularity of the Spring "framework pattern templates" would be limited only by the amount of time that Interface21 and the contributors have to contribute and maintain them.

The current problem is essentially this: We are being told by Spring to fit a round peg (say, the Pet Clinic sample) into a square hole (the app you and I are currently designing/writing). Your app often bears little resemblance to the sample given...once you finally "induce" (draw conclusions and generalizations about) the full "framework pattern" from the sample app.

For example, what if your app actually NEEDS the JSP page to scroll through 1000 rows of data, and allow the user to in-line edit 50 of the rows?

This can easily be done in some apps (such as TOAD), but what is the best (or at least a) Spring "framework pattern" for that? and where, please, is the "framework pattern template"? This would clearly answer someone's question earlier in that thread asking how would Rod or Juergen do such and such, i.e. what would Spring recommend.

In addition, the samples (all of today's vendors', i.e. not just Spring's) do not clearly separate the documentation of the "plumbing" (how it goes about wiring up its objects, resources, etc.) from the app functionality (pets). This is what makes it so hard to induce the various framework patterns and sub-patterns from the samples. There is much patterning going on in the samples that is merely implied and not stated.

If Spring can start to separate out the plumbing from the app functionality, via some kind of "framework pattern documentation", then the true "framework pattern template" begins to emerge, and becomes useful to anyone who happens to need that particular pattern.

Further, there would be much less architecural debate about how to design your layers and services and such. (That would all be stated in the "framework pattern". The debates would be more "fine-grained", about, say, how to "clone-and-morph" the existing "framework pattern template" to accomplish some exotic or unusual task.

To be fair to the Spring people, they may currently have their hands full, just moving their framework forward. I mean, I imagine they have a life, too...or...hmm...maybe they've figure out how to clone themselves.

But even in were I work now there is some people who like job protection just too much ... its a too bad ... software developemt is a dificult topic, the world would be a better place if we would all help each other out ... *whishfull thinking*

...and to be fair to the people trying to protect their job, even if they had the time, they are not always allowed to give out their existing "framework pattern templates". In fact, sometimes, they're working their butts off, just trying to KEEP their job.

This is where the value of framework pattern templates provided by groups such as Spring would pay off for everyone: Less time debating how to design within a framework and more time coding of cost-effective, easy-to-maintain app functionality from pre-existing framework pattern templates.

Ben

[Colin Yates]

Good post.

To be honest, I think sample applications can only go so far....they have to be naively simple to illustrate the point.

I think also, the combination of all of the Spring books ("J2EE without EJB", "Java Development and the Spring framework" etc.) and the reference manual, *and* all the excellent javadoc go a long way to giving you all the info you will need.

I am not sure that "framework patterns" are the right term, the examples you give are more architectural patterns applied in a given framework (I think).

The other problem is the maintenance of all of these things.....there will always be another "common" task which isn't covered by the 26million combinations of approaches...simply because people do come up with different solutions to the same problem.

I hear what you are saying, but I don't think it is anything to do with the framework, I think it is more like an architectural blueprint.

[debasishg]

I am not sure whether to call them "Framework Pattern Templates" or "architectural blueprint". But with the number of options in enterprise Java development exploding day by day, I am sure we, the developers need much more streamlined guidance from the Spring leads. A very nice example will be Colin's blog post on validators in Interface 21 blog space. There has been lots of questions from the community on this issue in the post, which goes to prove that people are still confused about best practices. Another example on the same line will be to have the best practices for DDD implemented in a fairly comprehensive blueprint that addresses issues like DTOs (and when to use them - remoting ?), domain objects as controllers, aspects and LTW (there are number of issues with LTW) etc. Another huge area will be to address application scalability problems for enterprise applications - replacements for SFSB etc.

Just my little thought.
- Debasish

[Colin Yates]

A very nice example will be Colin's blog post on validators in Interface 21 blog space.

Yeah, but I have heard very dodgy things about that bloke

You are right of course, I was quite suprised by the amount of feedback that blog generated. I thought I would pick what I considered a fairly "safe" post, but I was obviously wrong

[tatvamasi]

Yeah, but I have heard very dodgy things about that bloke

You are right of course, I was quite suprised by the amount of feedback that blog generated. I thought I would pick what I considered a fairly "safe" post, but I was obviously wrong

Normal fued between DBA's and Developers comes on Collin's blog, what do you expect?

[karldmoore]

Your thread does highlight and mirror lots of issues that I am having and countless others seem to be having as well. I do agree with one of the replies though, architectural blueprints might be a nicer term.

As with most other people I've done the book tour (J2EE without EJB, Domain Driven Design, Patterns of Enterprise Application Architecture, Core J2EE Design Patterns, Spring for Dummies, Java for Idiots etc...) and that has got me so far down the track. I've developed with these technologies and learned from the tutorials, reference materials, forums and experience but I'm still left wanting. Articles like this help (http://www.onjava.com/pub/a/onjava/2...ngwebapps.html) but again its too simplistic.

Want I would LIKE to do is prevent people from making the mistakes in the first place by giving them a BETTER understanding of how to solve boilerplate problems. I've seen so many times how not to do it, I can't be alone in that. Why can't we demonstrate best practices on a larger scale, is it a time and maintenance factor or is this what the Spring training is for?

Spring has spoilt us by providing great technology, what we need to do now is learn how to successfully apply it. I appreciate this comes with experience, but I really don't want to have to join a company that got it wrong. I've seen it first hand and it isn't pretty.

After lots of reading I'm more confused then when I started. Threads like this (http://www.theserverside.com/news/th...hread_id=38047) just show you how a simple example can cause such extremes of opinion. Good job powers like Martin Fowler and Rod Johnson wade in put people back on the right track.

What I would like to see are high level blueprints for common application architectures. If this is in a more rounded sample application as well then great! We can all demo the simplistic application, lets have a go at something more meaty. I have some time, does anyone have the inclination?

[whipshaw]

I have been in the process of training 4 new programmers on Spring and the application architecture of many of our projects and haven't found there to be too many problems.

I really do think Spring is very well engineered and easy to learn for the most part. Essentially it is just abstracting away many of the annoying complexities of many Frameworks and J2EE in general. I've found a few cases where I wasn't "in love" with the abstractions Spring provided, but because Spring follows some nice "rules", it has always been easy to further abstract the Spring stuff or make my own abstraction that did the job for that particular project.

There are a wealth of good books I can recommend (especially books by Martin Fowler or Rod Johnson). I don't know if I'm just old fashion or something, but I'm tired of new phrases like "Framework Pattern Templates" that I know damn well won't help my green programers any more then me forcing them to read Fowler's Refactoring or EAA book or even just the Spring reference manual.

I don't think this stuff is as complicated as people think it is. If I don't understand something about the way Spring works, I load up Spring's source in IntelliJ and usually the code is VERY self documenting. It is usually easy to see why they used a particular pattern or strategy. I just try to keep our architecture simple, clean very well tested.

My biggest challenges with the new programmers has alway been the more abstract things, like teaching the "modivation" for why we are doing something a particular way or trying to make some methodologies "second nature" to them.

For example, I'll peer program with the programmers and tell them, "alright, we want to make a UserFormController". If they don't start my going into the test directory and making a UserFormControllerTest I start banging my head over the keyboard. The methodologies and modivation is what is hard to teach (and have adoped). The Spring Framework is usually a peice of cake.

[karldmoore]

Let me know which books you'd recommend, I'd be interested in having a look.

I don't think you understood what the threads original author is getting at. Spring Framework is easy, its great, there isn't a debate here about that. I agree it isn't complicated quite the opposite, it does a great job of keeping things simple. You really aren't going to here a bad word from me on this one, its made my life so much easier. Now I can focus on the hard parts of development, which are sometimes further simplified thanks to Spring (BOY I do love Spring).

I also agree that the hardest thing is understanding why something was done like it is, thus helping people pick up on these habits and replicating them in the future. Test driven development, great lets do that, I understand all these arguments. I always mistrust people who just nod their head and don't ask WHY questions, people need to understand and appreciate motivations to take them on board.

BUT, if you sat one of your new programmers down and asked them to design a new system from scratch, would they know where to start and would they get it right? They know Spring but do they know how to apply it to a given problem? (I realise these are subjective)

There seems to be lots of confussion once you start to think about the layers above the service layer (web tier, remote facade, etc....), and when you read so many contradictory statements (DTOs are evil, OpenSessionInView is evil) I would like to guidance from a trusted source.

I really don't think we are that far away from this already, Rod Johnson sets out some straight forward standard architectures in J2EE without EJB. What I'm after though is an extension to these overviews with suggestions about how to fill in the gaps.

How many people are currently writing a web application that talks to a database, hands up. Right well these are the blueprints for how to develop an application (OpenSessionInView, Detached Objects, Service Layer transaction and security, Dao Layer, Rich Domain Model, Validation here, Exception handling like this, etc....) Need remoting? Well its a good idea to do it like this.

I would like to train people with blueprints of standard architectures using Spring and related technologies. These can explain the WHYs of the architecture and best practices to use. The more systems people interact with the more they understand architecture. So lets give them something more then the most simplisitic examples and help people get it right. People do have the tools now at there disposal and the technologies. I do truely wonder though if they have the right information.

[Colin Yates]

I absolutely think this would be a good thing, but I don't think a book is the right way.

The only way to "get" this stuff is really to learn by experience, either your own or other peoples (obviously), the problem is that I don't think a static commentary is going to impart all this information. The most interesting thing about the "right" architecture is all the things that aren't *wrong* with it, and also all the things that aren't a part of it. Does that make sense?

In other words, I could say "when you right a web app on a single JVM manipulating an object model then use a POJO domain model backed by an ORM tool etc. etc.". The problem with this is that a new person wouldn't understand *why* this was the right technology; and more importantly why I didn't choose a whole host of other architectural styles/patterns.

For someone who understands Java and the different architectural flavours (EJBs v POJOs, procedural/aneamin v DDD etc.) I think the most effective way to learn is to sit next to, and argue with a more experienced developer.

"Static knowledge transfer" can only take you so far, at some point you need to check your reasoning/decisions with a clever bod

And yes, i21 is full of these clever bods and do provide consultancy or workshops etc. (I am only doing the salesmen bit because someone mention CoreSpring training ).

[Colin Yates]

To put it another way, when I make a decision to go one way, I am also excluding all the other ways that I know about....the interesting info is why I didn't choose all of the other options....that isn't going to come across in a book

Also, a lot of the rationale for choosing an architecture isn't about static variables (hardware, requirements, development platforms etc.) it is about the team knowledge/level of expertise, turnover of staff, maintenance infrastructure, testing infrastructure etc.

I will stop rambling now