I have been fooling around with Scala, Lift and Spring the last couple of months.Why? I want to see if this combination of libraries and languages can make me more productive than my current preferred application stack. I also like the prospect of having to write less linear text (stuff like getters and setters) in order to accomplish something.
Underlying this is a wish to kill off the factory (and, up to a point, the singleton) pattern. When I first started using Spring a number of years ago, a new world opened in terms of maintainability of my code. Inversion of Control (IoC) was the enabler of this leap forward. I think I have only written a handful of factories since.
I am basically looking for a stack that
- has some kind of inversion of control that enables regression testing outside of a container/in an IDE without requiring deploying test structures in production, or changing code to run tests.
- has declarative transaction control, along the style of Spring’s @Transactional annotation. Many of the Scala/Lift examples I see has little or no transactional demarcation.
- has most of the infrastructure stuff I need already present – I do not want to even hear people talking about how easy it is to roll your own. I want stuff to be mainstream and recognizable. None of the companies I work for make money off of doing infrastructure like ORM. It might be symptomatic that Scala so far has two ORM frameworks (Mapper and Record), and three Actor implementations. I expect this flurry of library creation to die down after a while, though. Java wasn’t much better around 2001.
- enables me to separate my applications along vertical layers, and which helps me separate presentation and business logic. This does not mean I want nonfunctional wrapper layers.
- is efficient and bug-free.
It turns out other people is thinking along the same lines as I do. A good discussion can be found in this thread. This is a discussion between java/spring based people like me and the authors of libraries like Lift. One side wants IoC, the other says not to bother and use something like Lift’s Boot class instead. And at a superficial level, this isn’t too bad.
The boot class used by Lift looks like a stripped-down Spring XML bean definition list: “Class A needs to have an instance of class B”. I mostly don’t do these kinds of configuration items any more. I tend to declare my services using an annotation (@Component or @Service), and telling beans that use then that they need something injected (@Resource). I think this is cleaner since all the information about the wiring of my application is right there in the code, where it is easy to find for other developers.
My Spring config files deal with transactional support, databases, security, ORM – and test support. I also really, really like the pre-made test libraries that come with Spring. They make it so much easier to get people started with regression tests. None of these are available in Scala, and it seems to be somewhat less than trivial to retrofit these parts of Spring to Scala.
I haven’t decided yet, but I do know that I don’t like my production Boot class knowing about my test structures. Need to think about this for a bit.
Actually, I tell a lie. As usual with spring, it is just a question of who creates what.
I tried to wire something into a lift snippet. These are classes (Didn’t think. I would have made them objects since I don’t want one for every page view, but that is me. They are classes, and I didn’t catch that because I thought I knew what I was reading.)
So – I added a <context:component-scan> element to my application context. I then made a small change to my snippet, called AuthorOps:
@Component("authorops")
object AuthorOps {
var hibernateTemplate : HibernateTemplate = _;
@Resource{ val name="hibernateTemplate"}
def setHibernateTemplate(ms:HibernateTemplate) = { this.hibernateTemplate = ms}
}
class AuthorOps {
def list (xhtml : NodeSeq) : NodeSeq = {
val temp = AuthorOps.hibernateTemplate.findByNamedQuery("findAllAuthors")
(...)
And all of a sudden, the wiring works. Lift can create as many instances of the class as it likes, while Spring gets to wire the object.
Admittedly, this is a bit of a hack, but at least I managed to get spring to hook into some scala code. Hooray.
Now, I wonder if I can do the same to the transaction support…
Kent Tong has done a blog post mixing scala, spring, hibernate and wicket. If this post tickled your fancy, I suggest having a look at his post at http://agileskills2.org/blog/2010/06/19/getting-started-with-scala-spring-hibernate-wicket/