I've a c#.net project that uses multiple 3rd party dlls. These dlls exposes interface that are used throughout the project. My question is this: These interfaces are passed to the constructor of Controller class like this:
HomeController(IClientData clientdata, IClientRecord clientrecord)
{ }
Here clientdata and clientrecord are initialized to a default value needed to start the view(produces a list of client details). I've to use these initialized data somewhere else in my project but I don't know how to get these default initialized values.
What you have seen is a very general pattern in ASP.NET MVC . Here your home controller has 2 dependencies (one class inherited from IClientData and other from IClientRecord) . These dependencies are usually injected by some DI framework .
There are some good DI frameworks available for ASP.NET MVC
Unity
Autofac
Castle Windsor
StructureMap
etc...
and they usually provide two ways to setup the dependencies -
through XML configuration files
Fluent interface (inside code)
When Fluent interface is used, a general practice is to create a separate class file inside App_Start folder and call it from global.asax (Application_Start).
Related
How should I configure Autofac so my Console Application doesn't have to add a reference to each different implementation of an interface?
I have the following project structure:
App.Core - Class library containing interfaces that will be used on the other class libraries
App.ImplA - Class library implementing interfaces from App.Core
App.ImplB - Class library implementing interfaces from App.Core
App.Console - Console Application referencing App.Core and using Autofac to inject the right reference to the implementation classes
Examples on Autofac website suggest adding the following code to the main project, which in my case is App.Console:
var builder = new ContainerBuilder();
builder.RegisterType<SomeClass>().As<ISomeInterface>().InstancePerDependency();
var appContainer = builder.Build();
But, if I want to decide which implementation class/assembly should be used via config, I won't have a reference to the assembly with the implementation (am I wrong?). Thus I won't be able to reference SomeClass on RegisterType function.
How can I do this? Is it right?
Depending on how your app and assemblies are structured, I think you have basically two options.
If all of the implementations are in the application at the same time - for example, you have both the implementations for a SQL Server data access layer and for an Oracle data access layer - then you are stuck with configuration. You may be able to make some of the typing easier by registering multiple related types in an Autofac module and then using configuration to switch modules instead of individual types. For example, all of the SQL Server type registrations would happen in one module and all of the Oracle type registrations would happen in a different module. Configuration would indicate which module to run - a one-line change instead of many lines.
If you can structure your app to only include implementations you want to use then you can use assembly scanning to do the registrations. Basically, search for all of the things implementing your interfaces and register them all on the fly. You can also combine this with Autofac modules by searching for and registering all modules found in application assemblies.
I'm creating an MVC 5 site with Web API 2 functionality inside it as well and I'm wondering how I should work with the fact that ASP.NET uses 2 different resolver instances for resolving MVC controllers and ApiControllers.
I found this article that explains how to configure the resolution, but it looks like it uses 2 separate container instances and doesn't explain how to register dependencies for each. It's just like "do your registration here."
Following the 2-container example, I was tempted to set up the app so that the Web API container only has Web API dependencies and the MVC container only has mvc controller dependencies, but I feel like in the situation where a component is used for both, having a subset of items used in both containers would be too much work to maintain correctly.
Is it okay to just have all of the dependencies installed in each container? Or is it better to use the same container in each resolver?
Edit: I'm not using Unity so I'm writing a resolver class to wrap Windsor. I'm considering having my resolver implement both interfaces and just assigning the same instance as the different resolvers as well.
I am pretty new to MVC and I am currently working on an MVC 3 project in visual studio and I want to create a method or variable that is accessible globally. When I say globally I mean available in my web project, service layer project, and data layer project.
I guess when I say global I mean global to the entire solution.
I tried creating a class in the solution items folder and referencing in my web project but its not letting me add a reference to the class since it is not a DLL.
I am a little confused with how to do this. Any suggestion would be appreciated. Also keep in mind that though I am a programmer I am still somewhat new to MVC and programming.
Edit: I have also tried adding a method in the global.asax file but was unable to call it
You should create a shared assembly where you define the class. You can then add a reference to the shared assembly from all projects that need the feature.
The class that you want to be "global" sounds like some sort of service. I suppose this is the kind of thing you may want to do with a logging service for example.
Using a logging service as an example it is generally best practice for the interface to the logging service be defined in a lightweight contracts type assembly. Then any of your assemblies that require an implementation of ILoggingService should inject the necessary implementation using an IoC container such as Autofac or MEF.
This pattern is pretty common and allows you to share common services while keeping implementations loosely coupled. Also this pattern will lead to highly testable code as fake implementations can be injected with Moq
I have an idea I'd like to implement which basically involves separating the controllers in an MVC4 Project to 2 different projects. The reason being I'd like to be able to have different controllers for an internal admin section of my site and for the external client section. I'd like to make changes to each of them individually and add a new DLL to the website as I make changes...the changes to the internal admin section of the site thus not affecting the controllers DLL for the external client section for example.
Does anyone know if this is possible/advisable or of a better way to accomplish what I'm trying to achieve?
taken from an artical :
"The MVC framework provides a default controller factory (aptly named DefaultControllerFactory) that will search through all the assemblies in an appdomain looking for all types that implement IController and whose name ends with "Controller." Thus, if you tell the factory to look for a "Home" controller, the factory can return a newly instantiated instance of a HomeController class regardless of the namespace or assembly it lives in—as long as it implements IController...."
by adding a reference to another project in you'r solution you can achieve what you are looking for, in that referenced project add you'r controllers. like written above the MVC Routing will find all controllers that been referenced in that solution.
I understand some of the functionality of Ninject and have been able to use it for IoC.
When I go to add a reference to Ninject to a project in VS2010, using NuGet, I see other Ninject extensions in the list. Specifically Ninject.MVC3. Also on the Ninject website under extensions ( http://www.ninject.org/extensions.html ) I see Ninject.Web.Mvc.
If I am creating MVC3 applications do I need to use this extension of Ninject? Does my basic use of Ninject for IoC with classes/interfaces require anything beyond the standard library?
What is the difference between Ninject and Ninject.MVC3/Ninject.Web.Mvc in an MVC3 project?
ninject.web.mvc is a ninject (core) complement for the ASP MVC (3) applications. Basically - you should use it, when you want to use Ninject in an ASP MVC project.
From the documentation:
This extension allows integration between the Ninject core and ASP.NET
MVC projects. To use it, just make your HttpApplication (typically in
Global.asax.cs) extend NinjectHttpApplication:
MVC 3 extension contains the crucial methods to wire up the DI composition root into MVC application - it means that Ninject will be responsible for instantiating your controllers, that has dependencies on other components (Ninjects 'overrides' the use of DefaultControllerFactory which is only able to create controllers with parameterless constructors).
In the documentation there are mentioned two methods, how to do it: either extending the NinjectHttpApliaction in global.asax or using the NinjectWebCommon class inside the App_Start folder.
There is also ninject.web.common extension, which is required for ninject.web.mvc. It contains e.g. the definition of InRequestScope.