[Play Scala 2.4.x] Patterns for Business Logic

[ßìnòy S]

Hi,

After successful deployment of a live application on Play 2.3, I started working on Play -Scala 2.4 based application. I am still new to Scala and have started liking the language.

But I have questions about design and structure for Play Scala apps.

Traditional MVC model design pattern allows for expanding it to MVCS ( Model-View-Controller-Service ) pattern, but seems like Play framework does not profess this pattern, I have seen all the business logic cluttered in the Controller in all the Seed applications or even templates.

What is the recommended approach / preferred pattern for implementing business logic with Play Framework. Is Service layer a thing of Past ?

If yes, I am not completely clear from Play framework documentation on how to wire the Service layer with Controller layer ?

Thanks 

[Casper Paulsen]

You can do it any way you want. After the controller part Play doesn't enforce a particular way of building your application. So if you want to structure the application the onion pattern way, service way, or a third way its up to you; Play doesn't enforce a particular pattern. 

Personally I use a mix of Service layers and command layers depending on what I'm doing. In general I use the onion pattern to structure the dependencies between different parts of the application.

[Gavin Baumanis]

There is no enforcement by Play for any set design pattern.

It is a convention only.

And there certainly is no "magic" to be had either.

Scala and Play do a lot of really ace things for you - but your application design is really up to you.

For the service layer, you can create it any way you like.

I was also a little thrown, initially, by there being a lot of business logic in the controllers of the example applications.

previously - the controllers, for me, were nothing but a list of steps (function calls).

Which made it easy to see what steps an action took, when fired off by an event.

Via this group and the Melbourne Scala users group - it was explained to me that it was common-place to have a lot of logic in the controllers - and that I should start seeing them as the interface between the model and view.

(Which of course they are).

But I have never visualised them like that before.

It was a little weird, for me, to be honest.

I am building an application like that at the moment, because I have been convinced that's "the way it is" and every one is expecting to see it that way - then for future-proofing / getting other people to work on the application - then it makes sense to do it the manner that others "expect".

Saying that : "I" am still not totally sold on it.

If you're still not convinced of the "fat" controller idea - you are of course completely free to desogn your application any way you like.

A companion object is a great place to start with your service code.

It is inherently attached to the class - and is automatically (via the compiler) a singleton, too.

Or, you can use a wholly other source file and create a XXXService class or XXManager class (Whatever you like to use as a naoming convention - for allyour publc API work.

Let me also give you this;

If you ever plan to use Akka, or the application is a large enough (load) that you feel the need to cluster / reverse proxy - make sure your code is immutable / stateless, from the start.

It will save you a lot of work and headaches down the track.

Again there is no "set" way for it - just about everyone will tell you that you data and structures should "always" be immutable.

Admittedly, at first it seems likea burden - but after a while you do get used to it.

The confidence you get as a developer from actually knowing that your data cannot change, is an amzing relief!

[ßìnòy S]

Thanks Gavin,

I too like the story-telling way of coding, and if controller is the entry-point I think its a nice thing to have the story of the functionality be told by the controller.

I generally have my application be stateless, except for some app wide caching of re-usable items.

[ßìnòy S]

Following SRP ( Single Responsible Principle ), I feel more comfortable with assigning the class / service contract to singular activity.