I need to display views in a Module.The Module Registers it's view using in Initialize method.
User will select module name from drop down list. First time it works using IModuleManager.LoadModule(string ModuleName). If I want to re-display the same module again(in the same region after clearing the previously displayed module) IModuleManager.LoadModule is not going to work. I dont know the views and regions contained in that Module. I know just ModuleName and I need to display it's view.
How can I do that?
Your questions is very confusing. Can you provide more information? The IRegionManager is the component to register Views to your predefined Regions. The ModuleManager is only responsible to load an assembly if I got that right.
I don't think you can Load a Module multiple times, because the second time it is loaded already. The logic for displaying views should be regulated via Services within your Modul so inside your Module should be a Method that uses the IRegionManager to register a specific View to a Region.
I don't know whether you use Unity or MEF ( or another IOC ) but you can obtain the IRegionManager within your Module via the Container.
Maybe you should watch this Tutorial series Prism Tutorial Series. It seems to me you are missing some basic principles
Related
I'm using DotnetCore, WPF and Prism 7 to make a desktop application. I have one service called DbConnectionService that doesn't seem to be created. This service is not injected into any component that is reachable through the View tree(?). Instead, it listens to the IEventAggregator and communicates with the rest of the app through that.
I'm finding that I'm not able to get it to 1. be created, and 2. if it is created it doesn't stick around (GC I assume).
Below is the code I have "shotgunning" anything that will create the DbConnectionService. All to no avail.
containerRegistry.RegisterInstance(typeof(DbConnectionService), "DbConnectionService");
containerRegistry.Register<IDbConnectionService, DbConnectionService>();
containerRegistry.RegisterSingleton(typeof(DbConnectionService));
containerRegistry.GetContainer().RegisterSingleton<DbConnectionService>();
Any help on getting this service to be created and stick around is greatly appreciated.
This service is not injected into any component
That's why it's not created. Either you inject it and rely on the container's magic to create it, or you create it yourself.
You can use the container to keep the object alive (i.e. not garbage collected) through RegisterInstance:
containerRegistry.RegisterInstance( containerRegistry.GetContainer().Resolve<DbConnectionService>() );
Note that Resolve isn't on IContainerRegistry to prevent you from doing this, because you don't want to mix registering and resolving. If you have to, make 110% sure that all dependencies of DbConnectionService are registered beforehand.
I'm new on angluarjs and trying to build an example-application.
This application is divided into 3 parts/sections:
A.) map
B.) "received"-area
C.) "send"-area
Every section has its own layout/view-area, not visible at the same time.
In part B.) you can load information from server by click or automatically, which will be displayed in part "B.)" as text and in section "A.)" as map-marker.
Additionally you can click inside section "A.)" to set a new marker.
In section "C.)" there is a send button to take the new marker from "A.)" in order to send this to the server.
Currently: all of the sections (A,B,C) are angular modules/own apps.
But I don't know, if that is the right way/best practice.
An other way could be a single module for the whole page an 3 controllers (A,B,C) which handle the logic for sections A,B and C.
What is the right way in angularjs?
From your description, I recommend designing it as a single AngularJS app with separate controllers for each view. It sounds like you would benefit from using an angular service to handle the client-side business logic and cache any shared data/models that could be used by the views. It is a best-practice in Angular to keep the controllers pretty lean and focused just on the view setup/binding and orchestrating the access to the services.
After searching the way to get some inspiration, i decided to realize the following think:
For all the self-made code, I use one module for the whole application and for all the external things, bundled with external plugins and services, I take a different module. This means: pne module for each "service-plugin bundle" (like google API & angular-google-maps plugin)
So I can switch the module, if the external service does not work, etc.
Looking at my example in the question this means:
Application part A: the map and all the map-specific things (set new marker, draw circle, etc) are insight a map-module. If I decide to use open street map instead of google maps i will plug in an new maps module
Application part A and B: this is my "main" app module with different controllers.
I have developed a silverlight prism project to replicate a memory leak. Just wondering about the lifecycle of a prism module.
If inside a module I register a view does the view get destroyed when the module is no longer in use?
Also does each module share the same dependency container (e.g. unity) or does each module have a separate one?
I have a more in depth question here,
https://stackoverflow.com/questions/4652364/memory-usage-is-suspect-when-loading-prism-modules
I am trying to understand some discrepancies with memory usage when opening and closing prism modules.
1) The point in time the view gets destroyed depends on the way you have registered the view to the container. If you didn't change the object lifecycle during registration, it will be destroyed when the GC finds it without having any object referencing it. If you explicitly specified a lifetime manager during the registration the view gets destroyed depending on the particular lifetime the manager manages. An exmaple: When you are using a Unity container and you registered the view with a ContainerControlledLifetimeManager the view gets destroyed when the container gets destroyed.
2) All modules share one container as long as you don't make a child container for each module on your own.
So I have two separate views in a WPF Prism app. How can I inject the same instance of a ViewModel into both the views via Dependency Injection?
(I assume you are using Unity as you mentioned DI directly and are not saying "Import" or similar)
Hi,
You will have to register the ViewModel as a singleton (using a ContainerControlledLifetimeManager) in the container and have it injected as usual. This ensures that you will get the same instance whenever you request for it.
A valid approach in this scenario might be to use a named registration in case you want to get the same VM injected elsewhere, but you don't need the same instance.
This article explains how to do this.
I have come across a bit of a problem while using Unity and WPF. The scenario is I have a WPF application which follows the MVVM design pattern. A have a module called ViewKDI. Within this module I have a service called ViewKDIService, the ViewKDIService service utilises another service called UserService.
Every time I load the module ViewKDI I want Unity to return me a new instance of both the ViewKDIService and the UserService.
I have put the below in the shell bootstrapper:
Container.RegisterType<IUserService, UserService>();
In the ViewKDI module I have put the following:
Container.RegisterType<IViewKDIService, ViewKDIService>();
Each time the ViewKDI module loads the ViewKDIService constructor is called. However the UserService constructor is only called the first time, this means that I am not getting a new instance of UserService.
I require unity to give me a new instance of UserService too so that I can manage this session separately from the rest of the application.
Any ideas?
Thanks
Faisal
Unity's default behaviour is to create a new instance of each object each time one is requested, so you shouldn't be seeing this behaviour.
From what I can gather from the source code and MSDN documentation (this is a good read), you can specify a "lifetime manager" object when you register a type to tell Unity how the type should be constructed and cached. Using the TransientLifetimeManager (which essentially does no caching) will cause Unity to re-create the class each time. So try this:
Container.RegisterType<IUserService, UserService>(new TransientLifetimeManager());
... and see if it creates a new UserService each time.