I am newbie in using Prism. I have created a sample application to understand it. I have some queries on, how it is working.
Question 1:
public class HelloModuleCls : IModule
{
IRegionManager regionManager;
IUnityContainer container;
public void Initialize()
{
RegisterViewAndServices(); // Injecting occurs here
if (regionManager.Regions.ContainsRegionWithName("ViewHolder"))
{
regionManager.Regions["ViewHolder"].Add
(
***container.Resolve().View***
);
}
}
protected void RegisterViewAndServices()
{
//since angular brace is not appearing, I am using ( , )....
container.RegisterType(IHelloView, HelloViewUC)();
container.RegisterType(IHelloViewModel, EmployeeVM)();
}
}
public class EmployeeVM : INotifyPropertyChanged, IHelloViewModel
{
public EmployeeVM(IHelloView targetview)
{
}
}
Upon hitting the line, container.Resolve().View,
the ctor of the VM, gets executed with, view type got injected in the param "targetview".
1. So, what will happen behind the scene, when that line got a hit...?
Question 2:
Project Name:- HelloModule (Another Silvelight Class Library referred in the startup Silverlight Application)
public class HelloModuleCls : IModule
{
public HelloModuleCls(IRegionManager rm, IUnityContainer um)
{
regionManager = rm;
container = um;
}
}
(Shell.Xaml) (In Startup Silverlight Application)
<ContentControl Prism:RegionManager.RegionName="ViewHolder" Grid.Row="0">
</ContentControl>
This Module is in another project. I am having the Region in the startup project. I have seen that, in the ctor of the HelloModuleCls, the region got which is used in the Startup project, got injected perfectly...
2. So, how the prism is passing those regions..... Is it like, once the region got created, then it will be injected to all the available Modules ctor or some other concept.
May I kindly know, how this is working out, So I can able to understand more.
Thanks in advance.
Answer 1: it resolve the one view, normally you want to register views with some key to be able to differentiate them.
Answer 2: it's the other way round, the regions exist in the application and the modules use them. They need to somehow know the name of the region, of course.
Unsorted comments:
RegisterType<ISomeInterface, OneOfItsImplementations>() lives in the Microsoft.Practices.Unity namespace, so add using Microsoft.Practices.Unity; to "see the angular brace appearing"
use something like regionManager.RegisterViewWithRegion("MyRegion", typeof(AView)) to make the view automatically appear in the region
to switch views in a region, have a look at prism's navigation features, like RegisterTypeForNavigation and RequestNavigate
the view uses the viewmodel, not the other way round. The viewmodel normally doesn't know about the view.
Related
I am working on application WPF in Prism framework.
Now I need two things . 1. a custom dialog box to show various custom messages and 2. Save and update and get Application Settings from a file stored in system by Json .
Now I have created a class which does the Jason related stuffs and have few APIs like get and set and save obj to Json and Json to Obj. Now I need this operations in all ViewModels of my class .
I do not want to create an instance of this class in all ViewModels separately.
So , I am looking for some prism supported services which can help in this direction.
I have seen this question (What exactly are "WPF services"?) but it is not giving me what I want or may be I am understanding the answers in this question.
I would be obliged if someone gives me a hints in this regards
First create an interface IJsonService and implement this on a class JsonService.
add these two functions in Interface IJsonService :
object DeSerializeJsonToObject(string fileName);
void SerializeObjectToJson(object obj);
Now in App.xaml.cs write the following code to register the service.
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
containerRegistry.RegisterSingleton<IJsonService, JsonService>();
}
Now go to any viewmodel where you want this service. Create a field like JsonService .
Modify the constuctor of the ViewModel like following :
IEventAggregator eventAggregator;
IJsonService JsonService;
public SensorConfigViewModel(IEventAggregator _eventAggregator,
IJsonService jsonService)
{
this.eventAggregator = _eventAggregator;
this.JsonService = jsonService;
}
Now you can access methods declared in the interface IJsonService and which are implemented in function in JsonService.cs
Just type JsonService.DeSerializeJsonToObject(....) and you can access the service methods.
I have used latest Prism nuget packages. In old Prism packages there could be some differences.
I have a module "Toolbar", "Toolbar" contains a UserControl and a ViewModel. The viewmodel is supposed to get a service called "IShapeService" injected into its constructor, however there's an issue.
I get the following error message when running my application:
The current type, Core.Services.IShapeService, is an interface and cannot be constructed.
Are you missing a type mapping?
The interface is mapped to the type in the ServicesModule which you can see below.
public class ServicesModule : IModule
{
private readonly IUnityContainer container;
public ServicesModule(IUnityContainer container)
{
this.container = container;
}
public void Initialize()
{
container.RegisterType<IShapeService, ShapeService>(new ContainerControlledLifetimeManager());
}
}
As far as I can tell by debugging, the issue is that the ServicesModule is not loaded early enough. I quickly tried using a PriorityAttribute (you can find it via google) on the module, but had no luck this time.
The weird thing is that it is working in another project with the same setup (as far I can see it is the same setup). The other project actually also uses the PriorityAttribute, but it is to determine tab order.
This is an image of the solution structure:
All projects reference the Core, but that is also it.
Can you spot what I'm doing wrong?
I've read the question Ioc/DI - Why do I have to reference all layers/assemblies in application's entry point?
So, in a Asp.Net MVC5 solution, the composition root is in the MVC5 project (and having a DependencyInjection assembly in charge of all the registrations does not make sense).
Within this picture, it is not clear to me what is the better approach among the following.
Approach 1
The concrete implementations are public class ... and all registrations clauses are centralized within the composition root (e.g. in one or more files under a CompositionRoot folder). MVC5 project must reference all the assemblies providing at least one concrete implementation to be bound. No library references the DI library. MVC project can contain interfaces to be bound with no drawbacks.
Approach 2
The concrete implementations are internal class .... Each library exposes a DI 'local' configuration handler. For example
public class DependencyInjectionConfig {
public static void Configure(Container container) {
//here registration of assembly-provided implementations
//...
}
}
which is up to register its own implementations. The composition root triggers registrations by calling all the Configure() methods, just one for each project. MVC5 project must then reference all the assemblies providing at least one concrete implementation to be bound. Libraries must reference the DI library. In this case, the MVC5 project cannot contain interfaces (otherwise there would be a circular reference): a ServiceLayer assembly would be needed to hold public interfaces to be bound.
Approach 3
Same as Approach 2, but local configuration modules are discovered dynamically through assembly reflection (by convention?). So MVC5 project has not to reference libraries. MVC project can contain interfaces and can be referenced by libraries. Libraries must reference the DI library.
What is the best practice here? Is there some other better possibility?
EDIT 1 (2016-12-22)
Thanks to received answers, I published this github project describing the best solution I found so far.
EDIT 2 (2018-09-09)
This answer provides an interesting option.
EDIT 3 (2020-12-29)
Finally, I came up with a complete solution, packaged in the form of a WebApi application template. I published this solution on GitHub HERE. This approach, not only gives a clear understanding about where DI rules have to be put, but also suggests to setup the application according to SOLID principles and CQRS pattern. The commit history of this project has been structured to have educational purposes.
EDIT 4 (2023-01-31)
The repository linked above publishes an article describing the solution as well.
I typically like to encapsulate these types of things into each project. So for example I might have the following. (This is an extremely simplified example, and I'll use the AutoFac in this example, but I'd imagine all DI frameworks have something like the following).
Common area for just POCOs and Interfaces.
// MyProject.Data.csproj
namespace MyProject.Data
{
public Interface IPersonRepository
{
Person Get();
}
public class Person
{
}
}
Implementation of Repositories and Data Access
// MyProject.Data.EF.csproj
// This project uses EF to implement that data
namespace MyProject.Data.EF
{
// internal, because I don't want anyone to actually create this class
internal class PersonRepository : IPersonRepository
{
Person Get()
{ // implementation }
}
public class Registration : Autofac.Module
{
protected override void Load(ContainerBuilder builder)
{
builder.Register<PersonRepository>()
.As<IPersonRepository>()
.IntancePerLifetimeScope();
}
}
}
Consumer
// MyPrject.Web.UI.csproj
// This project requires an IPersonRepository
namespace MyProject.Web.UI
{
// Asp.Net MVC Example
internal class IoCConfig
{
public static void Start()
{
var builder = new ContainerBuilder();
var assemblies = BuildManager.GetReferencedAssemblies()
.Cast<Assembly>();
builder.RegisterAssemblyModules(assemblies);
}
}
}
So the Dependencies look like:
MyProject.Data.csproj
- None
MyProject.Data.EF.csproj
- MyProject.Data
MyProject.Web.UI.csproj
- MyProject.Data
- MyProject.Data.EF
In this setup, the Web.UI cannot know anything about what is registered nor for what reason. It only knows that the EF project has implementations but can't access them.
I can drop EF for say Dapper extremely easily as each project encapsulates it's own implementations and registration.
If I was adding unit tests and had an InMemoryPersonRepository, how would I swap out the PersonRepository for my InMemoryPersonRepository?
Assuming we ignore any business logic layer and have an MVC Controller directly access our Data Accessor, my code might look like:
public class MyController
{
private readonly IPersonRepository _repo;
public MyController(IPersonRepository repo)
{
_repo = repo;
}
public IActionResult Index()
{
var person = _repo.Get();
var model = Map<PersonVM>(person);
return View(model);
}
}
Then a test using nSubstitute Might look like:
public class MyControllerTests
{
public void Index_Executed_ReturnsObjectWithSameId
{
// Assign
var repo = Substitute.For<IPersonRepository>();
var expectedId = 1;
repo.Get().Returns(new Person { Id = expected });
var controller = new MyController(repo);
// Act
var result = controller.Index() as ActionResult<PersonVM>;
// Assert
Assert.That(expectedId, Is.EqualTo(result.Value.Id));
}
You've identified a real problem. (One could say it's a good problem to have.) If entry application Areferences B, B references C, and B and/or C require some DI registration, that makes A (your entry application) responsible for knowing enough about the details of B and C to register all the dependencies.
The solution is to have a separate assembly that handles composing all of the registrations for B and C. A references that, and it provides all of the container configuration that A needs to use B and C.
The benefits are
A doesn't know more about B and C than it should
Neither A, B, nor C have to be tied to one particular DI framework like Unity or Windsor.
Here's an example. This is an event bus class that works best with a DI container. But in order to use it you shouldn't have to know all about the dependencies it needs to register. So for Windsor I created a DomainEventFacility. You just call
_container.AddFacility<DomainEventFacility>();
and all of the dependencies are registered. The only thing you register are your event handlers.
Then if I want to use the same event bus library with a different DI container like Unity I can just create some similar assembly to handle the same configuration for Unity.
I'm learning MEF and I wanted to create a simple example (application) to see how it works in action. Thus I thought of a simple translator. I created a solution with four projects (DLL files):
Contracts
Web
BingTranslator
GoogleTranslator
Contracts contains the ITranslate interface. As the name applies, it would only contain contracts (interfaces), thus exporters and importers can use it.
public interface ITranslator
{
string Translate(string text);
}
BingTranslator and GoogleTranslator are both exporters of this contract. They both implement this contract and provide (export) different translation services (one from Bing, another from Google).
[Export(typeof(ITranslator))]
public class GoogleTranslator: ITranslator
{
public string Translate(string text)
{
// Here, I would connect to Google translate and do the work.
return "Translated by Google Translator";
}
}
and the BingTranslator is:
[Export(typeof(ITranslator))]
public class BingTranslator : ITranslator
{
public string Translate(string text)
{
return "Translated by Bing";
}
}
Now, in my Web project, I simply want to get the text from the user, translate it with one of those translators (Bing and Google), and return the result back to the user. Thus in my Web application, I'm dependent upon a translator. Therefore, I've created a controller this way:
public class GeneralController : Controller
{
[Import]
public ITranslator Translator { get; set; }
public JsonResult Translate(string text)
{
return Json(new
{
source = text,
translation = Translator.Translate(text)
});
}
}
and the last piece of the puzzle should be to glue these components (parts) together (to compose the overall song from smaller pieces). So, in Application_Start of the Web project, I have:
var parts = new AggregateCatalog
(
new DirectoryCatalog(Server.MapPath("/parts")),
new DirectoryCatalog(Server.MapPath("/bin"))
);
var composer = new CompositionContainer(parts);
composer.ComposeParts();
in which /parts is the folder where I drop GoogleTranslator.dll and BingTranslator.dll files (exporters are located in these files), and in the /bin folder
I simply have my Web.dll file which contains importer. However, my problem is that, MEF doesn't populate Translator property of the GeneralController with the required translator. I read almost every question related to MEF on this site, but I couldn't figure out what's wrong with my example. Can anyone please tell me what I've missed here?
OK what you need to do is (without prescribing for performance, this is just to see it working)
public class GeneralController : Controller
{
[Import]
public ITranslator Translator { get; set; }
public JsonResult Translate(string text)
{
var container = new CompositionContainer(
new DirectoryCatalog(Path.Combine(HttpRuntime.BinDirectory, "Plugins")));
CompositionBatch compositionBatch = new CompositionBatch();
compositionBatch.AddPart(this);
Container.Compose(compositionBatch);
return Json(new
{
source = text,
translation = Translator.Translate(text)
});
}
}
I am no expert in MEF, and to be frank for what I use it for, it does not do much for me since I only use it to load DLLs and then I have an entry point to dependency inject and from then on I use DI containers and not MEF.
MEF is imperative - as far as I have seen. In your case, you need to pro-actively compose what you need to be MEFed, i.e. your controller. So your controller factory need to compose your controller instance.
Since I rarely use MEFed components in my MVC app, I have a filter for those actions requiring MEF (instead of MEFing all my controllers in my controller facrory):
public class InitialisePluginsAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
CompositionBatch compositionBatch = new CompositionBatch();
compositionBatch.AddPart(filterContext.Controller);
UniversalCompositionContainer.Current.Container.Compose(
compositionBatch);
base.OnActionExecuting(filterContext);
}
}
Here UniversalCompositionContainer.Current.Container is a singleton container initialised with my directory catalogs.
My personal view on MEF
MEF, while not a DI framework, it does a lot of that. As such, there is a big overlap with DI and if you already use DI framework, they are bound to collide.
MEF is powerful in loading DLLs in runtime especially when you have WPF app where you might be loading/unloading plugins and expect everything else to work as it was, adding/removing features.
For a web app, this does not make a lot of sense, since you are really not supposed to drop a DLL in a working web application. Hence, its uses are very limited.
I am going to write a post on plugins in ASP.NET MVC and will update this post with a link.
MEF will only populate imports on the objects which it constructs itself. In the case of ASP.NET MVC, it is ASP.NET which creates the controller objects. It will not recognize the [Import] attribute, so that's why you see that the dependency is missing.
To make MEF construct the controllers, you have to do the following:
Mark the controller class itself with [Export].
Implement a IDependencyResolver implementation which wraps the MEF container. You can implement GetService by asking the MEF container for a matching export. You can generate a MEF contract string from the requested type with AttributedModelServices.GetContractName.
Register that resolver by calling DependencyResolver.SetResolver in Application_Start.
You probably also need to mark most of your exported parts with [PartCreationPolicy(CreationPolicy.NonShared)] to prevent the same instance from being reused in several requests concurrently. Any state kept in your MEF parts would be subject to race conditions otherwise.
edit: this blog post has a good example of the whole procedure.
edit2: there may be another problem. The MEF container will hold references to any IDisposable object it creates, so that it can dispose those objects when the container itself is disposed. However, this is not appropriate for objects with a "per request" lifetime! You will effectively have a memory leak for any services which implement IDisposable.
It is probably easier to just use an alternative like AutoFac, which has a NuGet package for ASP.NET MVC integration and which has support for per-request lifetimes.
As #Aliostad mentioned, you do need to have the composition initialise code running during/after controller creation for it to work - simply having it in the global.asax file will not work.
However, you will also need to use [ImportMany] instead of just [Import], since in your example you could be working with any number of ITranslator implementations from the binaries that you discover. The point being that if you have many ITranslator, but are importing them into a single instance, you will likely get an exception from MEF since it won't know which implementation you actually want.
So instead you use:
[ImportMany]
public IEnumerable<ITranslator> Translator { get; set; }
Quick example:
http://dotnetbyexample.blogspot.co.uk/2010/04/very-basic-mef-sample-using-importmany.html
I have been searching for a while.
I'm not new to dependency injection and have used StructureMap with several projects MVC and the like, but I felt like giving Ninject a go, so as not to miss out on the fun.
I am trying to use Ninject with an existing web app which I am bringing up-to-date.
I couldn't find on the blogs and wiki provided by Ninject, I am a little impatient to be honest so may have missed it, and the first few pages of google appear to be out of date or talking about using MVC with Ninject.
So far I have the following and it works, but I was hoping someone could point out a less intrusive option, regarding calling the ServiceModule to the Kernel and injecting a property with the desired bind from the web app.
What I have so far is a ServiceModule:
public class ServiceModule : NinjectModule
{
public override void Load()
{
string connectionString = ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;
Bind<IPreRegistrationService>().To<PreRegistrationService>()
.WithConstructorArgument("connectionString",connectionString);
}
}
Then in my page I have defined a private variable:
private IPreRegistrationService xfemPreRegistrationService = null;
Then in the page load event:
IKernel kernel = new StandardKernel(new ServiceModule());
xfemPreRegistrationService = kernel.Get<IPreRegistrationService>();
So this works, but what I would like is to move on to a phase where all I define is:
[Inject]
public IPreRegistrationService xfemPreRegistrationService { get; set; }
on a page and the rest is magic.
Cheers
Thanks to this stackoverflow post I found out about the extension Ninject.Web
Problem I found was you need to start off using Ninject.Web and I could not as I already have a PageBase defined to handle securities and the such.
So, the only way I could see was to take the KernelContainer class from the project (as KernelContainer is defined as internal):
Then call from the global asax OnApplicationStart:
KernelContainer.Kernel = new StandardKernel(new ServiceModule());
// Request injections for the application itself.
KernelContainer.Inject(this);
Then in my PageBase from the OnInit method:
KernelContainer.Inject(this);
This has allowed me to reach my target of simply putting:
[Inject]
public IPreRegistrationService xfemPreRegistrationService { get; set; }
where needed