I am reading the chapter 11 page number 90 of clean architecture.
I agree with author that we should use interfaces instead of depending upon the volatile concrete classes to avoid the source code dependency on the concrete class to make our code more modular. He mentions the below pattern to handle the volatile dependency in the code.
In the above image author suggest to use the FactoryServiceImpl to create the instance of the ConcreteImpl.
What's the advantage we get in using the FactoryService? Anyway in the main method we will have to create the instance of FactoryServiceImpl and pass to the Application. Instead we can directly create the instance of the ConcreteImpl and pass it to the Application?
What's the advantage we get in using the FactoryService?
The application does not depend on FactoryServiceImpl nor ConcreteImpl. The advantage is that if you want to test the application class you can easily mock the FactoryService just by providing a test/mock implementation.
Since the application class does not depent on the concrete implentations, it is also not dependent on the dependencies of those classes. E.g. the FactoryServiceImpl might contain a dependency to an external service that it passes to the ConcreteImpl when it creates it - could also be a database. Maybe the FactoryServiceImpl uses a fancy framework that you don't want the application to "indirectly" depent upon.
Anyway in the main method we will have to create the instance of FactoryServiceImpl and pass to the Application. Instead we can directly create the instance of the ConcreteImpl and pass it to the Application?
Yes you could create a ConcreteImpl and pass it to the application, BUT Uncle Bob talks about volatile objects in chapter 11. This means that the application creates ConcreteImpl on the fly when it needs it. Maybe a ConcreteImpl is stateful and belongs to a user request. It might also be possible that the factory takes arguments that it uses to create a ConcreteImpl and this arguments change depending on the application state. Thus the application must create a new ConcreteImpl whenever the this state changes. Thus you can not create one instance in the "main" method.
Related
Suppose a Prism version 8 WPF module has a ViewModel which needs to call on a service.
the service implements IService, but there exists a number of implementations of this service. Each implementation is a file (class library), possibly as a IModule (see below).
The user shall be able to configure which file to use either by configuration or by a folder's content.
Obviously(?) I am thus thinking of Module discovery by creating the right type of ModuleCatalog while "bootstrapping" the application and the service could thus be contained in this module.
If the call is a void call ("fire-and-forget") I guess I could simply use EventAggregator (implementing the service as an observer), however the call returns a value.
What is the best approach solving this?
(I would like to avoid writing my own assembly "discovering/loading" of some kind of a swappable service implementation dll file)
If you can inject IEventAggregator, you can inject IService, can't you?
If no module registered an implementation, you'll get an exception. If more than one module did, the last one wins (with unity as container, at least).
I have a use case, that theoretically seems to me as it would be a solved problem. But i'm not able to find a sure fired implementation.
I've created a RESTful API, using Apache CXF, Spring and Hibernate
This application encompasses a standard Service-Proxy-DAO layered structure
I need to instantiate a custom logger object at my service (or pre-service) layer and initialize a bunch of parameters which will remain constant, for the most part through every call that goes through my application layers and back.
How can i, for every individual service call, initialize this logger object once, and use it across all my layers without having to instantiate it everytime. Either i inject the initialized object in every class i need or something on those lines.
I don't want to use static blocks, or pass the object in method signatures.
Is there anything that i can use as a part of the Spring, CXF or other java framework that allows me to implement this use-case.
EDIT: I would define a transaction as a single call to a web service endpoint, from invocation to response.
ThreadLocal would be an ideal candidate to solve your problem.
UPDATE:
Creating a thread local that is available in all the places where this "shared" reference is required will give all these contexts access to this resource without having to pass the reference around.
see http://www.appneta.com/blog/introduction-to-javas-threadlocal-storage/ - looks like a good explanation of how to use thread local and also deals with your problem space.
I'm a bit confused with DI and IoC. I have set up MVC and I use Ninject for properties injection and it works perfectly. My application is set to use Portable Areas from MvcContrib and each area is contained from providers, services, models and controllers.
Providers from one area can access other providers in same or sub assemblies. To resolve dependency in provider I use DependencyResolver.Cur... which is registered to use Ninject as well. I would like to know if this is a good approach since I don't want to pass all other providers from controllers to last layer, but I want to access them directly from provider. Should I create an instance of kernel in lowest assembly like Core so I can access it directly from anywhere?
Thnx in advance
UPDATE:
I would also want to know if it is possible to use property injection in normal class.
When you design all your services (reposities, application services, controllers, etc) around the constructor injection pattern, there is no need to call DependencyResolver.Current.GetService from within a class and there is no need to make an instance of the kernel available in the lowest assembly.
When all your services use constructor injection, your container will be able to construct an object graph of dependent services when a root type is requested: in your case a controller class. When you do this, no code needs to access the DependencyResolver or the Kernel directly, which ensures your code will be more testable, flexible, and maintainable. Any code that accesses the DependencyResolver or static Kernel instance is hard to test, hides its dependencies, and makes it difficult to verify the container's configuration in an automated fashion.
Instead of using constructor injection, you can achieve the same with property injection. However, since the convention is that properties are for optional dependencies, Ninject (and any other container) will skip a property it can't inject (implicit property injection), instead of throwing an exception, as would happen with a missing constructor argument dependency. This again makes it much harder to find configuration errors in your application. So, whenever possible, stick with constructor injection.
I updated Ninject.MVC3 package from 2.2.1.0 to 2.2.2.0. Before I had access to the Kernel object through BootStrapper.Kernel property but in the new version Kernel property is marked as obsolete. I get a warning saying
'Public ReadOnly Property Kernel As Ninject.IKernel' is obsolete: 'Do not use Ninject as Service Locator'.
Is there a different way to access the kernel in the new version?
If you have a class that (for some reason) needs to retrieve objects from the Ninject kernel, you can include the kernel as one of the injected properties/constructor parameters on the class. This pattern is better in the sense that you're explicitly declaring that a particular class is using the kernel, rather than always having it available as the service locator pattern does.
This assumes that Ninject automatically adds an instance binding of the kernel to itself. I know that it used to do this, but if it doesn't you can add the binding manually.
The reason why this has been marked Obsolete and will be changed to internal in future is that people tend to use Ninject as a service locator if it is possible to do so. But Service Locator is an antipattern that should not be used. And as we don't want to provide functionality that helps building badly designed software it will be removed in future.
If this needs a lot of changes in your code this is sign that your code is suffering from this malaise Dependency Injection wise and you really should change it to a better design.
Limit your access to the kernel to a mimimum. There is almost no situation in MVC where you need something other than plain constructor injection. Therefore my first advice is to refactor to constructor injection where possible.
For these very rare cases where you need access to the kernel to create other objects you should inject a factory to the class that needs the new instance and inject the kernel into this factory (if the Constructor has a Kernel parameter, it'll receive the instance doing the injecting).
If you really want to stay with service locator even if almost everyone will tell you not to, you will have to keep a static reference yourself.
In ASP.NET MVC 3, I think DepedencyResolver is a clean way to get a service locator.
You could use the Common Service Locator as a service location hook into Ninject. The Common Service Locator only allows you to retrieve objects though, not inject objects that you already have. Of course you could hack around this restriction, but you could just as easily create a static class that exposes the Ninject kernel and reference that rather than the BootStrapper.
I see use of Up and Down (aka setUp, tearDown) functions in MVC environments. What do they mean?
Your question needs some better definition, but in general these methods usually indicate that some other framework or resource is in control of the lifecycle of the object you are in. They act as leaf methods, invoked by the framework (in the case if a JUNit test) after the test framework has created all the required plumbing and instantiated your test. Since you don't get to create your own constructor, the framework will invoke setUp() for you. Any code you would have normally placed in a constructor would go here. The opposite is true of teardown. You are not controlling the lifecycle of some object, but you may have created or consumed shared resources that need to be unallocated or returned before the end of the life of the object. The tearDown method is an indicator you should release resources and prepare your object to close up shop (so to speak)