first of all, ideally the DI container you are using shouldn't affect your class design at all. Its only job is to assemble your components.

 

I have used the cake pattern in a medium-sized application and have to admit I still got mixed feelings about it.

 

Alternative thought: To reduce the number of types in Scala you can also make use of functions and/or structured types for your injection needs. This is what I ended up making lots of use of, it makes unit testing very easy - no mocking needed, since all you pass in as dependencies are callback functions.

 

I know (but never used it myself) that Jan Machacek has done quite some work on using Spring to assemble your Scala components, see e.g. http://skillsmatter.com/podcast/scala/spring-scala

 

hth,

Erich

 

From: [address removed] [mailto:[address removed]] On Behalf Of Noel Kennedy
Sent: 14 February 2013 17:21
To: [address removed]
Subject: Re: [lsug] Dependency Injection

 

We use the cake pattern after a brief fling with just using abstract fields.  

 

I have run into the path dependent type problem a few times since we refactored to using cake.  Briefly our problem was caused by trying to share an instance implementing a contract, from one cake inside another cake.  Every time this happened it made me realise I was actually trying to share state and I refactored out an actor or a singleton or whatever and the problem goes away.

 

 

Pick a good naming convention for your traits if you go with cake as you will need it!

 

You can use ours if you like

 

 

trait xxxDependency {

 

trait xxx {} // The unimplemented service contract.

 

def xxxService : xxx

}

 

trait xxx{implementation name}  extends xxxDependency {

 

//self type to all other dependencies

 

trait {implementation name} extends xxx {} //actual implementation of service

}

 

 

 

 

 

cake cons

 

Head scratching to work out how it works

Boiler plate traits

Path dependency type problem discussed above 

 

cake pros

 

Compile time checking of dependencies.  

Everything is wired up in code 

(with an IDE) you can easily follow dependency graphs

One less framework that you need to learn and and fuss over.  

And no xml

 

 

 

Cheers,

 

Noel

 

 

 

 

On 14 Feb 2013, at 15:51, Sandro Mancuso <[address removed]>

 wrote:

Hi all

We are starting a project with Scala but none of us are very experienced with it. 

We were looking for ways to do dependency injection and we found the following:

Cake pattern: 
http://www.cakesolutions.net/teamblogs/2011/12/15/dependency-injection-vs-cake-pattern/

http://www.cakesolutions.net/teamblogs/2011/12/19/cake-pattern-in-depth/

SubCut:
https://github.com/dickwall/subcut/blob/master/GettingStarted.md
http://vimeo.com/36217414

We also find a few dead repositories on github but nothing very relevant. 

I was wondering what you guys are using of DI in Scala. Pros and Cons?

Maybe because of my lack of experience in Scala, I found the Cake Pattern a bit verbose and SubCut a bit intrusive since I need to add SubCut stuff to all my classes. At least, that was my impression when reading the tutorial. 

Any views?

Thanks

 

Sandro Mancuso
Founder of the London Software Craftsmanship Community

Twitter: @sandromancuso

Blog: http://craftedsw.blogspot.com

Book: Software Craftsmanship: Professionalism, Pragmatism, Pride

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Sandro Mancuso ([address removed]) from London Scala Users' Group.
To learn more about Sandro Mancuso, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

 

        

This message, together with any attachments, is intended for the stated addressee(s) only and may contain privileged or confidential information. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal Veterinary College (RVC). If you are not the intended recipient, please notify the sender and be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Unless stated expressly in this email, this email does not create, form part of, or vary any contractual or unilateral obligation. Email communication cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, amended, lost, destroyed, incomplete or contain viruses. Therefore, we do not accept liability for any such matters or their consequences. Communication with us by email will be taken as acceptance of the risks inherent in doing so.

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Noel Kennedy ([address removed]) from London Scala Users' Group.
To learn more about Noel Kennedy, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Erich Eichinger ([address removed]) from London Scala Users' Group.
To learn more about Erich Eichinger, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]