MVC and DAO patterns used in reactivemongo play-scala app

[alex reviyou]

Hello team,
we are looking at the samples of reactivemongo with play to make sure we use best practises and code standards..

we have a few quetsions
you project sample uses MongoController and in general - make db call to mongo from the controller layer which is always considered to be bad in java for exmaple
https://typesafe.com/activator/template/modern-web-template

when we look at the older sample - https://typesafe.com/activator/template/play-mongo-knockout
looks like it had DAO layer, services etc, so both MVC and DAO patters were applied.

Can you please advise us on best practices here? which solution would you recommend and why? We use reactivemongo, play, mongodb etc..

I am trying to find any reason not to use MVC patters for the growing application for the best maintainability etc..

Thanks in advance,
Alex on behalf of reviyou team..

[alex reviyou]

I add a reference to the ticket we had created before without realizing that google group if much better place for that(https://github.com/ReactiveMongo/Play-ReactiveMongo/issues/78)

[Stephane Godbillon]

Hi,

You don't have to use this trait at all. You can perfectly write custom DAOs in a specific layer – many ReactiveMongo users do that. This trait is provided as a helper for simple use cases.

Cheers,

-- Stephane Godbillon

Blog: http://stephane.godbillon.com

Twitter: https://twitter.com/sgodbillon

Github: https://github.com/sgodbillon

--
You received this message because you are subscribed to the Google Groups "ReactiveMongo - http://reactivemongo.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reactivemong...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pedro De Almeida]

Hi Alex,

You can have a look to this experimental DAO design:

https://gist.github.com/almeidap/5685801

https://gist.github.com/almeidap/9660665

https://groups.google.com/forum/#!topic/reactivemongo/pISkeicl0Fk

It's currently under refactoring but comments and suggestions are welcome!

Cheers,

Pedro

[alex reviyou]

Thanks Everybody, all very helpful!

Alex

On Tuesday, April 15, 2014 1:52:42 AM UTC-4, alex reviyou wrote:

[alex reviyou]

Pedro I looked over your samples and have a few question.

DId you intentionally used objects instead of classes for your DAO implementation. It seems like covering your DAO's with Junits if it was a class would be more natural.

Also I am trying to understand the concept of using DAO in scalable controller. 

If you simply reference your object, does the architecture  locks you in any way?

Essencially your objects are singletones, so if you have a 1000 concurrent users calling the same DAO method -

 what would happen with this object? 

And also how many references\connections gets create to some mongo collection?

Analogy in java\spring  would be each service defining an object with a prototype scope and reference this object in controller, 1 object per request, and connection pool to the database is managed separately. 

Here using object and referencing it directly from controller I assume - is confusing me a bit since I don't completely understand how would it work at scale.

Btw it looks like you lean towards DAO rather than ActiveRecord, any reason why in case of reactivemongo+play+scala integration?

[Fehmi Can Saglam]

There should not be a performance problem while using functions in singleton objects as soon as they are non-blocking.

I am trying to create a library for DAO and DSL support for ReactiveMongo. I have released a snapshot version. Documentation is not complete and does not match the code actually. If you want to try I will suggest looking at tests. I would appreciate any feedback. 

https://github.com/fehmicansaglam/reactivemongo-extensions

[Valtteri Pirttilä]

Hi Alex,

Spring controllers, services and daos are singletons, just like Scala objects. Just like in Spring, if you use objects, you will have a single class, not one per request.

Spring prototype scoping would be the same as using classes for controllers/services/daos instead of objects.

I come from a Java Spring background as well and I've enjoyed Play very much. I use simple references to objects as they are quite simple to use and cover just about all my use cases. If you really need more advanced dependency injection, then you might want to google the "cake pattern". To be honest, I believe it's just unnecessary complexity for most apps, but of course needs vary in different projects.

[alex reviyou]

Valtteri,

I don't think it's entirely correct statement. Spring services and daos are just a spring beans, that could be singleton , prototype, session or anything really, depends on the developer.

By default spring bean is defined with a singleton scope but that' it.

But I agree with your point of using singletons without states and make sure they are thread safe for better scalability whenever it's possible.

And I agree that dependency injection is too much extra complexity for the relatively small apps.

Prototype scope should be used only if singleton is not enough, even even than you can easily replace it with your own factory pattern for a simple cases.

In scala for DI you can use cake pattern which has some drawbacks too or "structural typing approach", type-safe and somewhere simple, well described in the internet.

Or implement a third party framework for DI as well(there is a bunch of those working OK with scala). 

But again in our case we'll try to keep it simple I guess and stick to the singletons and makes sure they are thread-safe, thanks everybody for the advice.

[Pedro De Almeida]

Hello Alex,

To complete what Fehmi Can and Valtteri said, remember that you can return asynchronous results (i.e. a Future[Result]) with Play! framework (in fact, it seems that any kind of Action is asynchronous, see here):

http://www.playframework.com/documentation/2.2.x/ScalaAsync

"The web client will be blocked while waiting for the response, but nothing will be blocked on the server, and server resources can be used to serve other clients."

... and that the ReactiveMongo API manly returns Futures and Enumerators:

https://github.com/ReactiveMongo/ReactiveMongo#scale-better-use-less-threads

"ReactiveMongo is designed to avoid any kind of blocking request. Every operation returns immediately, freeing the running thread and resuming execution when it is over. Accessing the database is not a bottleneck anymore."

This means that a business call will return almost immediately and end up with nested or chained Futures. If I correctly understood, the Futures will then be resolved by the Akka (actor/eventing) system on which Play! and ReactiveMongo rely on. Your concerns about concurrency are mainly handled by Akka and, as long as you don't use Await, you probably resolved most of your performance issues.

Let me just add a personal advice. When I successively discovered Scala, MongoDB (via Java first) and Play! framework, it took me a long time to admit that I was just doing it the wrong way. I had to forget (or throw away) my knowledge, "best practices" and other specificities that I inherit from my background as a Struts/Spring/JavaEE developer in order to embrace this new functional, asynchronous and reactive world. But even today, I keep challenging my implementations as I did not yet get rid of these (bad) habits.

Cheers,

--

Pedro

[Rajesh Bansal]

hi i am also from same background ,i want to learm play .can you please suggest me what will be beneficial for me .i want to learn play mvc fast,please suggest me

[David Patrick]

A while back ago I wrote an answer to a similar question on codereview.stackexchange.com. Maybe it will be useful to you as well.

Any comments regarding that answer would be appreciated. It's been a while since I've looked at the theory on this subject. I'll try to take a look at some of the other answers here myself to see what else I can learn.

 - David P.

On Tuesday, April 15, 2014 1:52:42 AM UTC-4, alex reviyou wrote: