I am new in MEF. I am working on a C# WPF application and using Prism with MEF.
Please tell me how can I create single instance per thread of a class using MEF.
Thanka a lot
DJ
In the current version of MEF, you would need to develop a complex hierarchy of containers in order to accomodate this requirement (singleton per thread). Since you are new to MEF, this would be quite tricky to implement. Here is a link with more information about this:
http://codebetter.com/glennblock/2009/08/16/should-i-use-mef-for-my-general-ioc-needs/
I believe one of the new options in the new version of MEF (currently called MEF2) will be better options for how to handle object instantiation. You can read more about it at the BCL blog or here:
http://mef.codeplex.com/
Related
I can't seem to grasp the modules of dagger.
Should I create a new instance of a module each time I want to inject stuff?
Should I create only one instance of a module? If so where should I do it?
Is there a more complex example of fragments and activities used with dagger?
Thanks
You should think more about #Component than #Module. Modules just create objects that need further initialization. The actual work happens in Components, which modules are part of.
Should I create a new instance of a module each time I want to inject stuff?
You should create your module when you create the Component it is part of, since only this component is going to need it. If you find yourself creating the same module multiple times, you are most likely doing something wrong.
A module uses additional arguments (pass them in via the constructor) to create more complex objects. So if you were to have e.g. a UserModule you'd pass in the a user to create user dependent objects from the resulting component. If the user changes lose the old component and create a new module and a new component—the old objects should not be used anymore.
Keep the component where / when appropriate and be sure to use Scopes, since they determine the lifetime of your component.
Should I create only one instance of a module? If so where should I do it?
You most likely will just create a single instance of #Singleton annotated Components and Modules. In android you'd most likely keep the reference to the component (not the module!) in the Application or some real 'singleton'.
Is there a more complex example of fragments and activities used with dagger?
Try googling. There are lots of high quality tutorials with linked github repositories that go into much more depth and detail as would be possible here on SO. e.g. see Tasting dagger 2 on android.
In my hunt for various GUI frameworks, I remembered GTK being a fairly mature library for making user interfaces for desktop applications.
And it got me wondering, is it possible to use the Glade interface designer with Scala? Is there perhaps a Scala-optimised framework or library to make the process more painless?
It appears that there exists a GTK+ binding for Java, and from an unofficial source it seems like you can use this in Scala.
This binding contains class Builder with method addFromFile(), so you should be able to create a UI file in Glade, save it, then load it in your Scala project, and use the method getObject() to access the objects defined in Glade.
For more details you can refer to this question and its answers, which deal with Java, but should be very similar to Scala.
As Scala is interoperable with Java, you can use it's bindings. I highly recommend you to first see a scala REPL micro tutorial for Ubuntu then read and understand what is GtkBuilder and how to create Gtk+ interfaces using Glade. Then a proposed process could be:
Create your apps UIs using Glade
Call GtkBuilder in your Scala code to interact with UI parts (send receive data)
Create Scala script file for each UI
Create a separate backend app with REST interface to present app input/ouput as UI state changes
Connect the two apps
By doing so, you'll get a set of bash scripts (written in Scala) each draw a native UI when executed. Whenever the backend is running, it's possible for UI to be used as I/O of backend app.
All,
There has been a lot of posts about Unity Lifetime Managers but I have yet to find someone state a good rule of thumb for "in these cases you should always use X". Let me describe my application, I have an ASP.NET MVC 4 Web Application. I have a Visual Studio solution containing 3 projects, my 'Core' project which has all of my EF stuff, a testing project, and the MVC Web Project. I am using Unity for dependency injection and have the following code right now:
// Context
container.RegisterType<IDatabaseFactory, DatabaseFactory>(
new ContainerControlledLifetimeManager();
container.RegisterType<UnitOfWork>(
new ContainerControlledLifetimeManager());
However, I'm noticing that my context is not recreated with every new web request which is what I think I would want (let me know if I'm wrong in that assumption). I'm having a hard time analyzing all of the information from the sites listed below and have read about a lot of people creating their own class named PerHttpRequestLifetimeManager to handle this.
What truly is the best practice here?
Understanding Lifetime Managers by Microsoft's Developer Network - http://msdn.microsoft.com/en-us/library/ff660872(v=PandP.20).aspx
MVC DI & Unity with Lifetime Manager via CodeProject - http://www.codeproject.com/Articles/424743/MVC-DI-Unity-with-Lifetime-Manager
ASP.NET MVC Tip: Dependency Injection with Unity Application Block via Shiju Varghese's Blog - http://weblogs.asp.net/shijuvarghese/archive/2008/10/24/asp-net-mvc-tip-dependency-injection-with-unity-application-block.aspx
MVC, EF - DataContext singleton instance Per-Web-Request in Unity via Stack Overflow - MVC, EF - DataContext singleton instance Per-Web-Request in Unity
Inject same DataContext instance across several types with Unity via Stack Overflow - Inject same DataContext instance across several types with Unity
Yes, you usually want one DbContext per request.
A PerHttpRequestLifetimeManager or child container created on every request are the typical ways this is handled.
The latest release of Unity introduces the Unity bootstrapper for ASP.NET MVC which has a new built-in lifetime manager: PerRequestLifetimeManager.
You can read more in the Developer's Guide to Dependency Injection Using Unity chapter 3, Dependency Injection with Unity.
I'm trying to design the architecture for a new LOB MVVM project utilising Caliburn Micro and nHibernate and am now at the point of looking into DI and IOC.
A lot of the examples for bootstrapping Caliburn Micro use MEF as the DI\IOC mechanism.
What I'm struggling with is that MEF seems to by reasonably popular but the idea of the Mef [Imports] annotations smells to me like another flavour of a Service Locator?
Am I missing something about MEF whereby almost all the examples I've seen are not using it correctly or have I completely not understood something about how it's used whereby it side steps the whole service locator issues?
MEF is not a Service Locator, on it's own. It can be used to implement a Service Locator (CompositionInitializer in the Silverlight version is effectively a Service Locator built into MEF), but it can also do dependency injection directly.
While the attributes may "smell" to you, they alone don't cause this to be a service locator, as you can use [ImportingConstructor] to inject data at creation time.
Note that the attributes are actually not the only way to use MEF - it can also work via direct registration or convention based registration instead (which is supported in the CodePlex drops and .NET 4.5).
I suppose if you were to just new up parts that had property imports and try to use them, then you could run into some of the same problems described here: Service Locator is an Anti-Pattern
But in practice you get your parts from the container, and if you use [Import] without the additional allowDefault property, then the part is required and the container will blow up on you if you ask for the part doing the import. It will blow up at runtime, yes, but unlike a run of the mill service-locator, its fairly straightforward to do static analysis of your MEF container using a test framework. I've written about it a couple times here and here.
It hasn't been a problem for me in practice, for a couple of reasons:
I get my parts from the container.
I use composition tests.
I'm writing applications, not framework code.
I am playing around with Entity Framework to see how it can be used in a new project I am working on. I put my edmx file in a class library so the Entities (and database access) can be used in multiple places. Currently I have a web project and a console project both referencing the class library.
One of my Entities has a Partial class defined with a static method. The purpose of the method is to accept some parameters and create one or more instances of the specific class. My first version of the method created an ObjectContext instance, created the Entity class (or classes), and returned the Entities to the calling method. The calling method then updated some properties and tried to save the Entities using a new ObjectContext instance. Obviously this did not work because the Entities were bound (correct term ??) to the Context created within the static method.
After some research, I modified the static method to also accept an ObjectContext reference to ensure that all the Entities where created and then later on manipulated and saved using the same Context. This works fine but the design just feels wrong.
Assuming that my one static method may grow into many more, or that my app (especially the web app) would probably benefit from additional layers (DAL or even a Service Layer), does it make sense for all these classes to require an ObjectContext parameter?
I have read on many postings that creating an ObjectContext via a Singleton pattern is a bad idea because "many clients would use the same object". My problem with that is I do not see how that is possible. In a local console app there is only a single user running the app. In a web app there would only be a single user on each request. Where is the user sharing problem? Not a single article/posting mentioned it...but where they referring to a Singleton pattern storing the object instance in the Application context?
I have also seen postings focused on web usage and storing the object instance in the users Session object via the HttpContext object. This makes sense but does not seem to address non-web usage.
I think that whatever solution is appropriate (static methodm, Factory object, etc.) would most likely be implemented in my class library so obviously it needs to support both web and non-web solutions. Maybe check for HttpContext to determine what environment it is running in.
I was hoping http://www.west-wind.com/weblog/posts/2008/Feb/05/Linq-to-SQL-DataContext-Lifetime-Management would be informative but I am having a hard time wrapping my head around the post and the example code seems like overkill for instantiating and sharing a simple object. (Although I am sure I am just not getting it...)
Any thoughts are appreciated.
Thanks.
The issue is not that “many clients would use the same object.” The issue is that the ObjectContext is intended to be a single unit of work. If you use it for many different units of work, you will find that there are a number of problems.
Memory usage will grow and grow.
Your application will become slower as object fixup has to do increasing amounts of work.
Multithreading won't work
The solution is to use the ObjectContext in the manner it is intended, namely, as a single unit of work.