Just learning about Dependency Injection and Prism...
It seems just asking around alot of people are using AutoFac as opposed to Prism...
Can you still use Prism in conjunction with AutoFac?
Or do you use Mef in conjunction with AutoFac
Sorry I'm jsut confused as to how it all fits together.
Thanks
PRISM has two types of DI container, Unity and MEF. Auto fac only provides the container (as far as I can see) while MEF/Unity provides several other things including the mvvm design pattern.
To answer your question, Yes you can use AutoFac as a DI container with PRISM, but then you are missing the possibilities of module loading and many more things PRISM provides with the MEF/Unity Container.
Edit: Just a quick side note, MEF is not a real DI Container. "you use MEF to really manage a set of unknown things, you use IoC Containers to manage a set of known things". - Glenn Block
Related
.. I'm new to ReactiveUI ..
trying to use ReactiveUI.Blazor .. in Blazor Server Side
.. it has been released but I can't see any examples in the solution
https://github.com/reactiveui/ReactiveUI/tree/master/src/ReactiveUI.Blazor
The only example I can find of Blazor with ReactiveUI
is https://github.com/Nethereum/NethereumBlazor and it's just using ReactiveUI .. not ReactiveUI.Blazor
Any one using ReactiveUI.Blazor ?
cheers in advance
Stu
ReactiveUI is never finished, but there are working samples for Blazor Server-Side (which is now released as of AspNetCore 3.1) and also working samples for Blazor Hosted and Blazor Client models in the ReactiveUI.Samples repository.
You can find the direct link here
TLDR: I had an amazing experience working with Reactive.Blazor in a WASM Blazor application and can absolutely recommend using it.
I used ReactiveUI.Blazor together with Blazorise in platform for managing offers in a more structured way to perform estimates based on the structured (meta)data of the offers.
I used the WASM version of Blazor and my experience was very good. Reactive functional programming (FRP) works well in React and Angular so it seemed like a good fit for Blazor as well.
My review:
The setup was pretty easy. I took a few notes from this arcticle and the code behind it.
I used DynamicData as well, which for me is somehow already part of the whole ReactiveUI stack. It fit very well into the whole application layout, although most of the components in Blazorise do not support the appropriate listeners for collection changes - there you need to support a bit with your code. I absolutely recommend using DynamicData as proxy/cache for your APIs though - state management has never been easier.
The easy form validation, which was a near natural fit for the Blazorise components was for me one of the major selling points - because I rely heavily on dynamic forms.
I am not too happy with the routing and IoC approaches yet. I am used to Autofac for most of my development, which I could easily use my services although for my views and viewmodels I had to rely on a service locator pattern (with Splat backed by Autofac).
I basically try to migrate my MEF code from Prism 4.0 to Prism 6.1.0 so first problem I ran into there was no CompositePresentationEvent anymore so I changed it to PubSubEvent. This gives me the a new exeption
To use the UIThread option for subscribing, the EventAggregator must be constructed on the UI thread.
so the way you could export and import the CompositePresentationEvent with MEF made no use of a EventAggregator instance at all you simple imported the event and MEF did the job.
So simple question is there some sort of best practice for migrate this kind of code or is it just simpler to stick with prism 4 ?
Regards
it's a little late but if someone was wondering what has been done in the end ...
in short, refactoring to use IEventAggregator but still using MEF to import/export a single instance of the EventAggregator.
I'm working on legacy code in a DotNetNuke module, trying to get classes and behaviors under a testing framework: I'm taking this opportunity to follow advice from the "Working effectively with legacy code" book, so what happens is that i'm trying to define areas which can be tested thoroughly and then converted to services. Then i'd like to use an IoC framework for it to work. For now, i've set eyes on Ninject.
However i'm hitting a design problem: as i'm in a DotNetNuke module, i can't really change application-wide structure: for example i can't derive the Application from NinjectHttpApplication. I can't use these suggestions from SO either.
I was thinking about having the Kernel in a static class that my module would set up and then use but from what i've read around it's a very bad idea.
So i'm starting to ask myself if it's possible to use an IoC in an application that hasn't been set up to support it from scratch. If i'm supposed to have a whole dependency tree loaded for each request, how can i rewrite legacy code locally and benefit from IoC? Is there a pattern where IoC use can grow out from very local rewrites?
Even though i'm working with DotNetNuke, any standalone component that can be installed into an independent framework begs the same question. Also i'm not targeting Ninject specifically, if another IoC framework can help in this case i'm willing to consider it.
From my experience, your best bet to get this type of abstraction within the context of DotNetNuke is by using the WebFormsMVP framework. This is really the only sane way I've found to do unit testing in a DNN module, and if memory serves I spent awhile trying to wire up Ninject a year or so ago.
But be warned, it is still WebForms and will never be drop dead simple. And without knowing your existing code base, I'd have a hard time knowing how easy it will be to make the migration.
I have a couple of resources on GitHub that you can check out for reference:
The first is a module template that should act as a solid starting point:
https://github.com/irobinson/WebFormsMvp-DNN-Module-Template
The second is a small example project:
https://github.com/irobinson/BeerCollectionMVP
Depending on the version of DNN you're using, it may or may not already ship with WebFormsMVP, but you should be able to either bundle the dependencies w/ your module or upgrade to the newer version of DNN if that's reasonable.
I have working on C#.NET project.In this project we follow CAB framework(Win forms). Now we plan to moving CAB to Composite Application Library for WPF. THis migrating process what are the things i have to consider, follow & learn?
View / GUI
XAML
dependency properties
two-way binding
Prism and Libraries
IoC, DI - Unity
Extension via Component Parts - MEF
event aggregator
I assume you're already familiar with application architectures that seperate business logic from UI logic, but for XAML applications and Prism in particular the MV-V-M pattern 'marries' the View to the business domain with less cumbersome hoops to jump than CAB.
Note that MEF is supported out of the box (alternative to Unity) with Prism 4.0, which is very recent.
See Also - MEF vs. IoC / DI
An excellent MSDN article that contrasts CAB and Prism
http://msdn.microsoft.com/en-us/library/ff921081%28v=pandp.40%29.aspx
I want to separate concerns here. Create and embed all the UI logic for the Custom XML designer, object model, validations etc in to a separate assembly. Then the Package framework should only register the designer information and ask for a UI Service and everything works magically.
This way I don't need to play with the Package framework (Visual Studio Package) assembly, when I need to modify the UI designer.
This question also applies to anything where you have to separate the UI logic from the Skeleton framework that loads it up, like a plugin.
I have several choices a ServiceProvider model, a plugin model or may be other.
Any samples, suggestions for patterns, links are welcome.
Update 1: What I am looking for is a thought such as - "Does Prism (Composite WPF) fit the bill? Has anyone worked on a project/application which does the separation of concerns just like I mentioned above? etc"
(I am still looking out for answers)
I've created a VSPackage that loads an editor. The Editor sits in a separate assembly and implements an interface that I defined. The VSPackage works with the interface, so any changes I make to the editor (and its assembly) does not affect the VSPackage as long as I don't change the interface.
What you're asking about seams very much like the separation of concerns that the MVC pattern tries to enforce.
ASP.NET MVC is already out there with a preview 5.
It's mainly for web but I think they are planning on using it also for WinForms, but I'm not sure.
I prefer the Model View Presenter pattern