I`m learning the concepts of composite applications.
I created prism application using unity container.
One of my regions configed as content control - In this Region, I want show just single view.
I`m using view injection in the next way:
object lastView;
// View injection
IRegion region = regionManager.Regions["MainRegion"];
var ordersView = container.Resolve<OrdersView>();
lastView = ordersView;
region.Add(ordersView, "OrdersView");
region.Activate(ordersView);
This the views in this region are switched frequently.
Before Im switching view Im using region.remove(lastView)
and than adding the next view like the code above.
Im not sure that its a good implementation, I have a few questions:
When I`m using region.remove method, Is the removed view being disposed?
Because if not after long run I will have serious memory leaks.
What is the best way implement single view in a region while avoiding memory leaks?
Thanks
By memory leaks I guess you're talking about whether the Garbage Collector is going to collect that view or not - e.g. is the container still referencing it when you remove it.
The decision on whether to keep a reference of the object after it's resolved is based on the type of the LifeTime Manager you used when you registered that object.
To answer your question shortly - The default LifeTime manager used with RegisterType is the TransientLifetimeManager, in which Unity creates a new instance of the requested type for each call to the Resolve or ResolveAll method.
What you're probably looking for is the ExternallyControlledLifetimeManager:
This lifetime manager allows you to register type mappings and existing objects with the container so that it maintains only a weak reference to the objects it creates when you call the Resolve or ResolveAll method or when the dependency mechanism injects instances into other classes based on attributes or constructor parameters within that class. This allows other code to maintain the object in memory or dispose it and enables you to maintain control of the lifetime of existing objects or allow some other mechanism to control the lifetime.
If you want to control the lifetime of your views, consider using the RegisterType with this LifeTime Manager.
Also, according to this article - The only lifetime managers which calls Dispose on resolved instances are ContainerControlledLifetimeManager (which creates singelton instances) and HierarchicalLifetimeManager. In these cases, the Dispose is only called when the lifetime manager is disposed.
Related
I want to create an instance of an object from an assembly that implements an interface I define in my Forms app. I would create this object at app startup using Activator.CreateInstance, and keep an application-level reference to it.
At certain points during this application I want to call methods on this object without holding up the main thread using Task.Run(() => IMyObject.DoSomeWork(someList, someList2)). I just want to make a "fire and forget" void method call and I don't need to await or even register callbacks.
Will the fact that the app is running in an STA thread pose an issue? Do I have to worry about leaks or premature collection of objects I instantiate on the main thread and reference inside the task closure? I only intend to read the contents of these lists, not modify them.
No need to worry; as soon as you create the delegate, all the objects it references will be kept in memory, at least until the Task.Run exits. There's nothing that an STA thread does that changes that.
Threads don't factor into GC at all - except that all stacks for running threads contain root objects. You can cross-reference objects however you want and it won't confuse the GC.
Does anybody knows why BlockData class doesn't directly implement IContent?
I know that during BlockData is being retrieve from database, proxy created by Castle implements IContent.
If StackOverflow isn't suitable place for this kind of a question, please move it.
Johan Björnfot at EPiServer explains some of the details in this post.
Excerpt:
"In previous versions of CMS was pages (PageData) the only content type that the content repository (traditionally DataFactory) handled. In CMS7 this has changed so now content repository (IContentRepository) handles IContent instances. This means that the requirement for a .NET type to be possible to save/load from content repository is that it implements the interface EPiServer.Core.IContent.
There are some implementations of IContent built into CMS like PageData and ContentFolder (used to group shared block instances) and it is also possible to register custom IContent implementations.If you look at BlockData though you will notice that it doesn’t implement IContent, how is then shared block instances handled?
The answer is that during runtime when a shared block instance is created (e.g. through a call to IContentRepository.GetDefault where T is a type inheriting from BlockData) the CMS will create a new .NET type inheriting T using a technic called mixin where the new generated subclass will implement some extra interfaces (including IContent)."
BlockData does implement IContent as it is intended to work both when added to another content item such as a PageData instance (a.k.a. Local Block), and as a standalone instance (a.k.a.Shared Block). In latter case the interface is added by using a mix-in though Castle Windsor so that it can be referenced.
The decision for this construct was based on wanting to be able to use the same rendering templates regardless if a block is local or shared. Therefor the choice stood between having a large number of empty properties on local blocks or the current solution using mixins. Both options were tested and mixins was selected as the preferred solution even though it's not a perfect one.
BlockData "does implement IContent", just do:
var myContent = (IContent)myBlock;
But, if you're by any chance handling a Block which itself is a property (not a ContentReference), that cast will throw an exception.
This will be true for 100% of all cases (... using Math.Round).
In WinForms, the WebBrowser control has a Document property in type HtmlDocument. The HtmlDocument instance has properties/methods like Forms, Links, GetElementsByTagName(), etc. that returns HtmlElementCollection instances. When I iterate over an HtmlElementCollection I am getting HtmlElement instances. These HtmlElement instances have DomElement properties which is a reference to the underlying COM object. My question is, should I call Marshal.ReleaseComObject() method on these HtmlElement instances or does WinForms manage the references internally?
Manual memory management is always a bad idea, particularly so with COM objects. You can get an opinion about it from the experts, the blog post from the Visual Studio team brings the point home pretty well.
Just in case you still think it is a good idea, the Winforms team has already made the decision for you. The interface pointer wrapped by classes like HtmlDocument, HtmlElement, HtmlWindow, HtmlElementCollection etcetera is a private variable of the class. You simply can't get to it, not without breaking every rule in the book anyway.
It is not entirely impossible to have a problem, these wrapper class objects are pretty small so you may have a problem with the garbage collector not running often enough to ensure the underlying COM objects are released. GC.Collect() is the fallback for that. Only use it if necessary.
If you don't call the ReleaseComObject function, the objects will be released automatically by winforms. Msdn says it can be used to control the lifetime of an object, but it is not necessary.
http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.releasecomobject.aspx
I have a form and several external classes (serial port, file access) that are instantiated by the form.
1) What's the simplest way to run an instance of an external class in its own thread?
2) Is the instance's thread automatically terminated when the form closes?
1) What's the simplest way to run an instance of an external class in its own thread?
Instances of classes do not "run". Methods do.
As such, you may want to look into the APM pattern and the BackgroundWorker class.
2) Is the instance's thread automatically terminated when the form closes?
It depends on how the threads were started. A thread can be a background thread or a foreground thread - the latter prevents the application from terminating.
If it's just a couple of lines of code you want to call asynchronously, probably the best way is ThreadPool.QueueUserWorkItem. See: What's the difference between QueueUserWorkItem() and BeginInvoke(), for performing an asynchronous activity with no return types needed
See if you are working with managed Environment, when an object is instantiated it will automatically dispose off if it is out of scope. The Disposal is actually taken care of by Garbage collection.
If you are using UnManaged objects, its your responsibility to close resources before making the object out of scope.
Garbage collection periodically turns on and start collecting all the objects that are out of scope. If you need to work on large objects, you can try using WeakReference class which will hold the object but also expose it for Garbage collection.
Read about WeakReference and garbage collection from here:
http://www.abhisheksur.com/2010/07/garbage-collection-algorithm-with-use.html
I hope this would help you.
The buzword in Linq now days is "unit of work".
as in "Only keep your datacontext in existence for one unit of work" then destroy it.
Well I have a few questions about that.
I am creating a fat client WPF
application. So my data context needs to track the entire web of instantiated object available for the user on the current screen. when can I destroy my datacontext?
I build a linq query over time based on actions of the user and their interactions with objects of the first datacontext. How can I create a new DataContext and execute the query on new Context?
I hope I was clear.
Thank you
Unit of Work is not the same as only keep your datacontext in existence for one unit of work.
Unit of Work is a design pattern that describe how to represent transactions in an abstract way. It's really only required for Create, Update and Delete (CUD) operations.
One philosophy is that UoW is used for all CUD operations, while read-only Repositories are used for read operations.
In any case I would recommend decoupling object lifetime from UoW or Repository usage. Use Dependency Injection (DI) to inject both into your consuming services, and let the DI Container manage lifetimes of both.
In web applications, my experience is that the object context should only be kept alive for a single request (per-request lifetime). On the other hand, for a rich client like the one you describe, keeping it alive for a long time may be more efficient (singleton lifetime).
By letting a DI Container manage the lifetime of the object context, you don't tie yourself to one specific choice.
I am creating a fat client WPF application.
Ok.
So my data context needs to track the entire web of instantiated object available for the user on the current screen.
No. Those classes are database mapping classes. They are not UI presentation classes.
How can I create a new DataContext and execute the query on new Context?
Func<DataContext, IQueryable<Customer>> queryWithoutADataContext =
dc =>
from cust in dc.Customers
where cust.name == "Bob"
select cust;
Func<DataContext, IQueryable<Customer>> moreFiltered =
dc =>
from cust in queryWithoutADataContext(dc)
where cust.IsTall
select cust;
var bobs = queryWithoutADataContext(new DataContext);
var tallbobs = moreFiltered(new DataContext);