On Tuesday, June 26, 2012 2:08:43 PM UTC+1, Christian Gruber wrote:
>
>
> On Jun 26, 2012, at 7:49 AM, Paulo Pires wrote: 
>
> > Hi all, 
> > 
> > This is a guidance request from someone who's interested in learning 
> Guice. 
> > 
> > I'm developing a Java SE application with some windows (SWT) that 
> interacts with the network (Netty.IO) and when some conditions are true 
> writes to a database by means of DAOs. Right now, my code is somewhat 
> tightly-coupled, so trying to put Guice to work is proving to be a true 
> PITA. 
> > 
> > My main issue is how to get instances from the injector in classes that 
> are 3 or 4 layers deep (not injected). 
> > 
> > I'd really appreciate if you could provide your approach on how you'd do 
> this. 
>
> Can you give a simplified source code example?  I'm not sure what you 
> mean.  If a class isn't injected by the Injector, then you can't get it, 
> unless the injected classes expose getters that let you obtain it through 
> these means. 


Imagine the following application workflow (I explain below):
AppMain -> MainWindow -> NetworkTestWindow -> NetworkClient -> 
NetworkClientHandler -> ResultDAO

AppMain - Where I instantiate my Injector and modules
MainWindow - main SWT window for user input
NetworkTestWindow - another window created from user input on MainWindow
NetworkClient - class responsible for creating a network connection 
(instantiated from user input in NetworkTestWindow)
NetworkClientHandler - class responsible for dealing with network events 
(onMessageReceived, etc.)
ResultDAO - A DAO class that *should* have EntityManager injected (already 
initiated in AppMain) in order to interact with the database

This was all tightly-coupled until some hours ago. Even though I can inject 
ResultDAO now, having to manipulate the SWT and network code to create 
windows with injection doesn't seem natural to me.

Is it a bad-practice to have a class like AppMain as a singleton, get the 
injector from there and use it to get ResultDAO instances?
 

>
>
> Often, it's very hard to move tightly coupled code into a 
> dependency-injection pattern, because it's really a substantial design 
> change.  often, I find it easiest to start in one of two ways- at the top… 
> take the big object and put it in the injector (the one that creates all 
> its dependencies), and start pulling out those dependencies and injecting 
> them in turn.  The other approach is to start with singletons, and re-tool 
> them so that their getInstance() methods have access to a global singleton 
> injector, and start migrating code that way.  There are lots of migration 
> patterns, and which one is optimal is really quite dependent on your 
> situation. 


Could you developer further this "access global singleton injector" 
solution? Or even better, could you please give your insight on how you'd 
structure the workflow I described earlier?
 

>
>
> But unless the Injector knows about the class (it's bound), then you can't 
> get it from the injector, you can only get it from a class that the 
> Injector knows about, which exposes it through accessors. 
>

Yeah, I learned this the hard-way. Nonetheless, it makes perfect sense!
 

>
> Christian. 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"google-guice" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-guice/-/0wr56UQHvgcJ.
To post to this group, send email to google-guice@googlegroups.com.
To unsubscribe from this group, send email to 
google-guice+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-guice?hl=en.

Reply via email to