The more I learn about J2EE, the more I’m developing a seething hatred for it. At least I’m making progress, though. At this rate I might even understand what everyone’s talking about by the time I need to start writing code! Which is like next week.
| I know what that is | Tutorials are fun | My own project works | I understand other projects | Fully programming | |
|---|---|---|---|---|---|
| Java | X | X | X | ||
| Maven | X | X | X | ||
| Tomcat / JBoss | X | X | X | ||
| Struts | X | X | |||
| Spring | |||||
| Hibernate | X |
go codey hamster go!
I’ve never heard of Hibernate in a J2EE environment.
My first reaction is “What bears do in the woods”, but I think that’s the punchline for a different joke.
How I see Spring
Spring is a KIND of way to abstract a project Framework.
Spring has every level of design set as an object (called JavaBean). Some of these objects are called “services” as they have static behaviors and after your initial bean everything is basically handled by services.
All services are defined in an XML configuration file called an applicationContext. I think it’s silly. There’s also one for the DAO objects called the dataAccessContext. These are really definitions for the Framework (BeanFactory and created beans) to know about each other and what beans need to work together at runtime (ServiceBeans that access DAOs that join on FKs include both parent and child DAO objects in the applicationContext.xml). dataAccessContext is just runtime configuration with data about tables.
Initially you define InputSetA as an object with your inputs as properties. You pass InputSetA to a service – InputSetAservice.validate(InputSetA); although it’s often called “.createInputSetA(InputSetA)”
This service breaks up the inputs and sends them off to other validation services (like the Hibernate DAObjects).
While it seems rather over-complicated, it allows developers to implement independently, the parts that they know while leaving plenty of room to refine later. Also allows for easy unit testing.
To get Spring working where I work you need…
BeanFactory, SessionFactory, some Constants to tell the BeanFactory what to make.
Then you need the actual ServiceBean definitions (like InputSetA) at every level which, when instantiated, makes all the subobjects/services necessary which make their own services, etc. at runtime.
These services are prototyped (service.impl.*)
and implemented (service.*)
and unit tested (service.test.*)
We also have a “ProjectDomain” which are the DAO objects proper (domain.*) and related servicebeans prototypes (dao.*)
and implementations…validation mostly (dao.impl.*)
That’s all I know. I didn’t understand it (and still dont fully) but I do like it. Very hard to get Eclipse to understand but rather simple to get working. Hard to figure out what’s wrong when you forget to define a context properly or prototype a new fun.