tags:

views:

106

answers:

2

I am starting to I am learning scala, and trying to build some simple applications to test drive the language more.

I am looking for non-intrusive framework/container for mid tier applications (not the web framework). Originally, I was about to start off with spring since I am very familiar with it. However, given that scala provides a very different way to do thing than java. I wonder if Spring is the best framework for scala that can take the most values out of scala. I'd love to know if there are new and better ways to do things in scala community.

My expectation to the framework/container will be able to address the following basic elements: configuration, modularization, monitoring(e.g. JMX), dependent injection. other things like JPA, JMS, conneciton pooling will be a plus.

I heard of Lift, but it seems to be more a web framework.

Thanks

+1  A: 

Have you looked into OSGi? What I have seen of Scala wrappers (ScalaModules) for it is pretty impressive.

Remember, though, that Scala can do dependency injection in a type-safe manner at compile time. I'm not trying to push you into it, just pointing out something you don't have with Java.

Daniel
A: 

I was in a similar position to you and I have kept with Spring: it has worked out just fine. The only annoyance is that my IDE (IntelliJ IDEA) has built-in Spring support and marks my spring config files as being full of errors when they are just fine.

I've found that one thing I can do instead of injecting multiple service implementations via Spring is to use composition of functionality using Scala's traits. For example, instead of using:

public SomeBusinessClass {
    private PersistenceService dao;
    private ValidationService validator;
    //setters, business logic etc
}

I might use:

public class SomeBusinessClass extends Persistence with Validation {
    @BeanProperty
    var dataSource: DataSource = _
}

Although this is not quite as flexible as the Java version, for most apps the flexibility of switching between service implementations is not really necessary. However, it does still preserve the fact that the persistent code is not co-mingled with the rest of the business logic.

oxbow_lakes