Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am new to the concept of Unity/Dependency Injection.
My understanding is that you use DI to avoid tightly coupled class structure but I am struggling to see its benefits.
I followed "The Unity Container" section on this link http://www.refactorthis.net/post/2012/10/25/Dependency-Injection-and-Inversion-of-Control-Ioc-With-the-Microsoft-Unity-Container.aspx but I do not know why this is "better" - it introduces a lot more code and still, inside LoggingModule.cs I still have to have this line of code:
_iocContainer.RegisterType(typeof(ILogger), typeof(DBLogger));
Meaning there is still a dependency but I have just moved it into a secluded location. I still have to tell Unity which class I want to use
This question will probably be marked as non-constructive but I would like to be told the benefits and how to use Unity/DI correctly.
Thanks,
Andrew
The benefit is that your services now depend on abstractions (ILogger) and the resolution of the abstraction is responsibility of the container. Besides, the declaration of your dependencies and which concretions to use and their life time is centralized in the Composition Root (the place where you register the dependencies in the container).
I suggest you to read a good book about dependency injection, there are several out there.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Can someone please explain why it is that in most of the documentation I’ve read everyone drums home the theory that it’s bad to include code in a Grails GSP yet, even in the same doc you find varying degrees of logic in a GSP? Is there some unwritten rule as to how much code a GSP should have or is it a judgement call as to what you think is safe?
TIA
There are several reasons. The main reason is because Grails roughly follows the MVC pattern, with a service layer added in. Most of your business logic should be in services or data services. Your controllers should only be concerned with taking in parameters (preferably in command objects), calling services, routing, and rendering, the views should just render the model sent from the controller. The controllers should just have templating logic, loops, and conditionals, but nothing that requires a transactions or bean references. Organizing you logic this way gives you a separation of concerns, and like the previous comment mentioned it makes everything easier to test.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm already using Dagger2 and everything is working but I have a doubt about the proper way to integrate it into the business logic.
What Robert Martin says in "Clean Architecture" is that the DI frameworks, since they are frameworks, are details that should be kept away from the Entity and Use cases and more in general from all the classes that are at a higher level than the frameworks.
What R.M. suggests is to allow only the Main-module to know the DI framework used and to inject the other classes by yourself in such a way that you can replace one DI framework with another one without having to change the BL.
Is there a way to isolate Dagger in such a way that the business logic does not see it?
Strictly speaking, yes: DI frameworks should also not be used in use case or entities circle. (That includes attributes and annotations)
The question would be how strict u want to handle this rule in ur project. Every rule and decision has pros and cons. As u said the pro of keeping DI out of the inner circles would be that u could easily replace it later. U would have to decide how big the benefit is compared to the cons, e.g.: having to pass dependencies to use cases manually.
Personally I currently try to handle it very strict in my projects. But my usecases tend to have only few dependencies ...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am new to IOC, I am building an Application where we are using IOC containers while discussing we decided an architecture that each module will have two Assemblies one for all module level work which is not exposed outside of that module and one with public access for the functions we want to expose outside.
My problem is I needs to create two IOC containers one at APP level and one at module level and there is a singleton instance which I want to register to both but the moment I resolve them two instances of the class got created on both levels is there a way to just get one instance.
One way is to create a Singleton class and inhibits to generate another instance but that I think will removed the concept of IOC is there any other way to just resolve singleton instance between two IOC containers.
Thanks
I am new to IoC, even I just understand the need of this concept few days ago. But, from your situation, why don't just rely registering the Singleton in one container while the other resolve from the one you registered.
Do this solution break concept of IoC too? I am sorry if this is not answer you search for. I am learning.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Coming from Android, I got used to Dagger as my main DI framework.
Recently, I joined a new iPhone project written in Objective-C which have no DI framework.
I would like to add one to our project, and I wonder which one is the best one to use, when it comes to simplicity and performance.
I would like to hear your opinion and experience.
Thanks!
Dependency injection is a popular design pattern in many languages, such as Java and C#, but it hasn’t seen widespread adoption in Objective-C (yet!).
This is an excellent read to get you started on DI is Objective-C. Additionally, you'll find this, this & the Grand Daddy this indispensable for DI in iOS.
This framework seems to be making a lot of noise these days.
In my personal experience, more than anything else DI helps you a lot in testing. It's not all or nothing approach (which is common for many design patterns) allows for easy, no-cost adoption & definitely valuable returns.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am new to grails. One thing I have noticed in the codebase of my current project is that the domain classes and the controller classes share the same package. So, you have something like this:
grails-app/controllers/foo/BarController.groovy
grails-app/domain/foo/Bar.groovy
So, is this a common practice? What are pros and cons of this? Thank you very much.
I think it's ok to use the same package for domain objects and controllers.
There is a practice called Package by Feature, which argues that grouping classes by what kind of component they are or what layer they are in is not as effective as grouping things together that contribute toward implementing the same functionality. When I work on projects packaged by layer I do a lot of hunting around going back and forth, grouping by feature would reduce that.
Usually domain objects have very little private about them. Also privacy in Groovy classes is nonexistent anyway.
This is how "convention" works over "configuration" in Grails. This is a common practice. I haven't found a demerit using it this way.
Normally, when you create-domain-class or create-controller even the tests are added in the same package as the domain class/controller respectively.
Best example of convention I can cite is when you use
grails generate-all yourPackage.Domain
Stumbled upon a similar post related to Grails where exactly the package by feature aspect as mentioned by Nathan is explained. Hope that helps.