Tag Info

New answers tagged

0

I will give a second answer, but you really should have opened a second question... First of all: you rarely ever implement a provider. Guice will automagically create them for you. To explain this: When I bind a class Foo as follows: bind(Foo.class).to(FooImpl.class) You can inject in you class either Foo or Provider<Foo>. Guice will create the ...


0

It's a bad practice to inject an injector, or otherwise pass it round in some way that makes it accessible to code outside of startup. That confuses what's going on; do that and when something goes wrong, you have to debug your code via debugging the dependency injection state. The right, static, way to do things is to inject either a hand-written factory ...


0

Ok, those are many questions you have and I guess some of the points can be approached in more than one way. Creating the injector is not cheap. Guice will do some analysis to detect errors as well as create all singletons. So you should create the injector at startup. I usually have a single injector for my application. Regarding your question 1.: Yes ...


0

I'm afraid you need to code the retrying logic yourself. However, this can be separated from the actual service call by utilizing the Proxy pattern. The RetryingProxy wraps the actual service and implements the error handling and retrying policy you need.


1

"SRP says methods should do just one thing". True. Constructors should do just one thing, and that is to put the object into a usable state. If just storing the dependencies doesn't put the object into a usable state, then the constructor isn't doing it's job. Did you read anywhere that "constructors with dependency injection should only set the ...


0

"It has some initialization that used to be done in the constructor but it seems that this is generally frowned-on in the DI world" - that's not exactly true. DI is just about providing dependencies externally not creating them within an object. So first thing fo you is to identify, within your singleton, what are it's dependencies and which are other ...


0

Not sure what language you are using, so I'm using pseudo-C# as example. You can create an IInitializes interface, which you then call after the instances are created. public interface IInitializes { void Initialize(); } public class PreviousSingleton : IPreviousSingleton, IInitializes { IDependency dep; public PreviousSingleton(IDependency ...


0

Have you looked into Aspect oriented programming ? https://en.wikipedia.org/wiki/Aspect-oriented_programming Maybe it helps ? An other idea would be to use an abstract factory to return the concrete implementation that you need to handle the error on runtime.


1

There are several things to consider here. It is worth reading up on the HTTP specification, specifically about idempotent rules, and to also consider a RESTful style of webservice interface. In short, if you implement a webservice with GET or HEAD, then in theory it should be safe to call multiple times with the same parameters, but webservices that are ...


1

What language are you using? Depending on the language(synchronious, asynchronious) you will have different solutions. If it is JavaScript, promise is indeed the way to go. Promises in JavaScript If it is something like C#, you probably don't want to have a loop like you indicated, because you will be blocking the thread. In that scenario, I would look ...


5

All three are wrong, because you are storing connection strings in source code. Source code is not the right place for configuration, because you are not expected to have to change your code (and so, do all the regression testing) every time your database moves or every time you move from development database to staging and to production database. Instead: ...


0

In addition to what Ian has said in his answer, the following should give you a different perspective around this thing. I try to answer following two questions about a dependency before I decide on the mechanism to pass the dependency object around. Am I going to be using the dependency? Who is responsible for instantiating the dependency? The answer ...


0

DI containers are generally used for plugging a limited number of long-lived objects together. Think of them as building the runtime structure of your program. Person looks like an entity to me - it will be loaded, used and discarded often. Also, you could potentially have an unlimited number of Person objects and it would not make much sense to use a ...


4

Well, for a start, the IOCFactory, or rather the way you described it being used, is a bold-faced lie, because it involves no inversion of control. If you continue calling getInstance() yourself, you should a least rename the alleged IOCFactory. As Ben Aaronson pointed out, a container without inversion of control is just a Service Locator. A lot has been ...


1

but I couln't convince him to use it because he thinks that the IocFactory "works as well so why not use it"... Because it's more complicated? Rather by definition, code that is doing more things has more things that can go wrong. For IoC containers, that often means lots of things going on under the covers to discover the various dependencies, resolve ...


0

What does the Spring framework do? Spring is as today not only, what was known as a simple framework, it is a complete ecosystem. Topics covered by the spring ecosystem: Spring Framework (e.g. Dependency Injection, AOP ...) Spring Cloud Spring Data Spring Batch Spring Security Spring Batch Spring Social See here for full coverage of the ecosystem. ...


1

In original Strategy pattern a strategy is injected into consumer. The code that is creating both consumer and strategy is responsible for choosing appropriate strategy. It is easier so if you can you should better stick to this approach. However, your problem is not uncommon - strategy has to be chosen in runtime based on input parameters. I see here two ...


0

A lot of people said here that DI is a mechanism to out-source the initialization of an instance variables. For obvious and simple examples you don't really need "dependency injection". You can do this by a simple parameter passing to the constructor, as you noted in question. However, I think that a dedicated "dependency injection" mechanism is useful ...


1

Right now what I see is the following chain of dependencies: client->controller->adapter->reader->controller That does create a circular dependency. You use Dependency Injection to achieve Dependency Inversion. That is, that higher level code does not dependent on the implementation of lower level code. Looking at the chain, we can attest ...


2

Yes I would rewrite it. Edit: new code based on your expanded comments and question: [assembly: InternalsVisibleTo("TestAssembly")] public class FakeModel { private IFakeDependency dependency; public string Name { get; private set; } public FakeModel(string name) { Name = name; ...


1

It looks like Dependency injection has been implemented in the MVC project. This is considered best practice these days and def superior to your two options! You would expect the services to be instanciated per request rather than singletons which would persist over all requests. (although these are sometimes used) However its not really clear that your ...



Top 50 recent answers are included