New answers tagged

0

Actually, the "right" way is to NOT use a factory at all unless there is absolutely no other choice (as in unit testing and certain mocks - for production code you do NOT use a factory)! Doing so is actually an anti-pattern and should be avoided at all costs. The whole point behind a DI container is to allow the gadget to do the work for you. As was stated ...


0

There is no "right way", but there are a few simple principles to follow: Create the composition root on application's startup After the composition root has been created, throw the reference to the DI container / kernel away (or at least encapsulate it so it is not directly accessible from your application) Do not create instances via "new" Pass all ...


1

First I want to mention that you are making this significantly harder on yourself by refactoring an existing project rather than starting a new project. You said it is a large application, so pick a small component to start with. Preferably a 'leaf-node' component that is not used by anything else. I don't know what the state of the automated testing is on ...


0

You say you want to use it but don't state why. DI is nothing more than providing a mechanism for generating concretions from interfaces. This in itself comes from the DIP. If your code is already written in this style and you have a single place where concretions are generated, DI brings nothing more to the party. Adding DI framework code here would ...


8

There are two parts to your question - how to implement DI properly, and how to refactor a large application to use DI. The first part is answered well by @Miyamoto Akira (especially the recommendation to read Mark Seemann's "dependency injection in .net" book. Marks blog is also a good free resource. The second part is a good deal more complicated. A ...


24

Don't think yet about the tool that you are going to use. You can do DI without an IoC Container. First point: Mark Seemann has a very good book about DI in .Net Second: composition root. Make sure that the whole set up is done on the entry point of the project. Rest of your code should know about injections, not about any tool that is being used. Third:...


0

Correct approach is to use constructor injection, if you use What I'm thinking about is that I can create a few specific factories which will contain logic of creating objects for a few specific class types. Basically a static class with a method invoking Ninject Get() method of a static kernel instance in this class. then you end up with ...


1

If you're talking about that page, the content is outdated because it deals with Enterprise Library 5, which was superseded with Enterprise Library 6 three years ago. If you read the paragraph just below the one you quoted, it directly answers your question about the alternative: The latest Enterprise Library information can be found at the Enterprise ...


0

I've managed to clean up my stateless classes by using default arguments. For example, virtual unsigned long foo( const ISomeInterface & dependency = ProductionDependency()) const override final; I appear to have met all the criteria in my original question... unit test stateless classes (without the dependencies) I can unit test by ...


0

I have seen the approach of adding a default constructor that calls the parameterized constructor with default instances, i.e. "poor man's dependency injection". public OrderWriter() : this(new TextFileWriter()) { } The regular code path calls the default constructor, whereas the unit test initializes using the custom constructor. If anyone could ...


0

The way to communicate between classes that have no knowledge of each other is via message passing. Usually there is a bus or some other form of master routing mechanism that each class registers with. From that point on, each class sends messages to the bus without any regard if another class is going to be reading them. So here, your lib is firing events ...


1

Keep it simple. GpsSensorUtil should have an event property, and ControlUtil should have a public event handler. Then, in your main code that creates the two, you should have a line like gpsSensorUtilInstance.GPSEvent += controlUtilInstance.OnGPSEvent;. No frameworks, no containers, no direct dependency between the two classes.


3

Since your UserControl is already decoupled from GpsSensorUtil by events, there is no need for dependency injection by interfaces, that would only complicate things without any additional benefit. However, if there are lots of events which must be wired up in a specific way together between those two components, it is a good aproach not to let this handle ...


3

If you're making a UI for the GPS data, it will invariably have a dependency on GPS data of some sort. Having that coupling isn't bad - quite the opposite. By having your user control depend on an explicit interface, you're letting the compiler be able to tell you when it's missing and you're telling your users what it needs to work. By making it an ...


0

Apart from DI, there is a class composition configuration at the root application (instead of configurating using xml). There is no need for any DI or IoC framework, even though they can tidy up the class composition configuration, particularly for large projects. This is because the DI framework normally come with container that implement additional ...


1

You could have separate classes for each queue and inject those, instead of injecting the factory. Your design as described here does not need a factory beyond the IoC-container as the type of queue can be determined at compile-time. Classes that need access to the queue can simply request an IUploadedDocsQueue or IRequestedDocsQueue as constructor ...


0

Looks largely ok to me. There's nothing to say that a factory should only have one method for creation. The Gang-of-Four book specifically has examples in which a factory creates families of objects (I think the example were GUI widgets for different platforms e.g. Motif windows/buttons vs. OpenLook windows/buttons or similar). From the book (and the link ...


3

I'd go with: Should I realise that expanding the API is a downside of Dependency Inversion, and be very clear about why I chose not to comply to it here? - Supports iteration 2 However, in The S.O.L.I.D. Principles of OO and Agile Design (a at 1:08:55) Uncle Bob says that his rule about dependency injection is don't inject everything, you inject ...



Top 50 recent answers are included