Tag Info

New answers tagged

0

To summarize: It looks like the only complexity comes from using improper configuration methods (yes, XML is not type-safe) and possibly also from frameworks doing much more work (Spring manages the object lifecycle, which goes far beyond DI). For a simple project, DI doing right is extremely useful: it allows to write services as tiny immutable classes ...


1

A library is supposed to be a black box with a clean domain-specific API. There's no problem with using any tools or patterns you need inside a library, including DI, as long as it does not leak to the client and constrain him in some way. If there's a need to provide extensibility or library configuration changes, it still can be done without sharing a ...


1

Truthfully, it doesn't really matter. There isn't much difference between a presenter-first design where the presenter subscribes to events on the view (observer pattern) and a view-first design where the view calls methods on the presenter instead of raising those events (potentially using command pattern, such as in MVVM). So long as you inject an ...


0

A process doesn't need to know everything about the game, but it might need to know about what the game does. This is the basic difference between classes and interfaces. (Part of the "D" in solid.) Imagine all of your objects as separate and completely unrelated. Then, imagine a single connection from each of those to a service that provides interface ...


-2

The beauty of external libraries is that they should do what ever it is they say they would do, while exposing a simple, straight forward interface. How ever complex it actually is to do it, should not be the business of the developer who implements it. If DI actually makes the work of the API developer less complex, then it makes 100% sense to use it, as ...


0

With manual/poor mans DI I could pass SMTPSettings directly into the constructor of EmailService and then inject EmailService into the StoreService constructor. This is also what needs to happen when using Ninject, except that you don't need to inject these values into the constructors, Ninject will do it for you - it recursively resolves all ...


2

Why is the purpose of this UserManager class?, you can use your repos directly when you need them. The name "Manager" its normally and advise of a class with a lot of or unclear responsibilities, who knows what a "manager" does?. Other thing looks a little strange in your design its that looks like if you are creating one repository per table or storage ...


-1

You don't need a user manager, what you need is to create an interface for each repository. So you will have IUserRepository, ITeamRepository and go on. After that you have to separate the logic from the factory using two different projects, I use to call the logic project DAL and the factory Resolver. You have to do this because if for example you are ...


3

The "instantiate my own collaborators" approach may work for dependency trees, but it certainly won't work well for dependency graphs which are general directed acyclic graphs (DAG). In a dependency DAG, multiple nodes can point to the same node - which means that two objects use the same object as collaborator. This case can in fact not be constructed with ...


0

As I mention in another answer, the issue here is that you want class A to depend on some class B without hard-coding which class B is used into the source code of A. This is impossible in Java and C# because the only way to import a class is to refer to it by a globally-unique name. Using an interface you can work-around the hard-coded class dependency, ...


1

I've not used Google Guice, but I've taken a great deal of time migrating old legacy N-tier applications in .Net to IoC architectures like Onion Layer that depend on Dependency Injection to decouple things. Why Dependency Injection? The purpose of Dependency Injection isn't actually for testability, it's actually to take tightly coupled applications and ...


4

When you swim at the shallow end of the pool, everything is "easy and convenient". Once you get past a dozen or so objects, it is no longer convenient. In your example, you have bound your billing process forever and a day to PayPal. Suppose you want to use a different credit card processor? Suppose you want to create a specialty credit card processor that ...


8

There is an old, old ongoing debate about the best way to do dependency injection. The original cut of spring instantiated a plain object, and then injected dependencies though setter methods. But then a large contingency of folks insisted that injecting dependencies through constructor parameters was the correct way to do it. Then, lately, as using ...


2

The best option would be the second one. This allows you to create stateless objects and also change the implementation in the future. The third one won't allow polymorphism and the first one will be statefull.


3

You construct them which ever way you need them constructed, and then you apply standard good practices to the resulting code - DRY, refactoring, single-responsibility, etc. There is a widespread impression that it is bad to spend too much effort on testing code because of a vague belief that it isn't "real" code. This is very wrong. Test code belongs to ...


3

a few things: 1) 10 dependencies is too much. you are probably missing a layer of abstraction. see: http://stackoverflow.com/questions/2420193/how-to-avoid-dependency-injection-constructor-madness http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/ 2)there are automocking frameworks like: https://automock.codeplex.com/ 3) theres also ...


2

What you can do is to create a factory, MainFactory that returns an instance of ConcreteMain as IMain. Then you can inject this Factory into your Runner constructor. Create the Main with the factory and pass inn itself as a parameter. Any other dependencies on the ConcreteMain constructor can be passed into the MyMainFactory via IOC and pushed to the ...



Top 50 recent answers are included