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.
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 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 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
In most ASP.NET Mvc tutorials, you see people creating simple models and then scaffolding controllers with views, using Entity Framework.
In most tutorials you will also see that they create a new DbContext class which will have the DbSets. I understand that this is a good thing to do for educational purpose, to help the person understand how it works.
But the account system that comes with a default Mvc project always links to "DefaultConnection".
Some tutorials will also make use of the account system to advance further, but that means that at this point you would have 2 databases running to support your web app.
one for the account info
one for the details of your model(s)
Is this the correct way to work? or do most developers/companies just use 1 database for both of these?
My reason for asking is because i found this tutorial which uses both of these aspects and works on 1 database and it is the first time i see this being done.
There's no right or wrong way. You need to evaluate the requirements and time lines for your projects and decide which options suits you best.From personal experience, in all the projects I worked on, the account info and the models reside on the same database.
Remember that if you have two databases you will need to create two data contexts to access them.If the database needs to be moved to another server, you would need to move two databases and change the connection string in two places, also the maintainance and upkeep on the DB would need to be performed in two different places.It's really a maintainance headache and should be avoided in my opinion unless your requirements have some compelling reason that you should place account info into a separate DB.
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 have read several articles discussing pros an cons about singleton patterns. But I would like to know:
Is it advisable to have multiple singletons in an iOS App?
what are the pros and cons...?
Currently I am having only one singleton globally and holding strong references of other necessary properties including custom composite classes. But the idea sounds something strange for me for an example, accidentally I can create several instance of a custom composite class which I don't want.
You should have as many singletons as you need. Take a look at Cocos2d - it contains a fair amount of them: CCDirector, CCTextureCache, CCSpriteFrameCache and so on. There's no limit on singletons, say 5. If it's convenient for you to have one single center class for a certain kind of operations (like accessing network or a database or whatever) and you never need a second instance of this class then feel free to make it a singleton.
It depends on your requirement.
You can have multiple singleton classes or objects.
The singleton object will be alive till your application quits.
For memory managing concern, it'll be very difficult if you have multiple singleton objects(You can't release these singleton objects, when a memory warning raises).
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.
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.