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
Related
I've seen references dating back 3+ years for Portable Areas in ASP.NET MVC, but then I ran across "Areas" for ASP.NET Core.
Are these the same thing?
Side question:
Is this something that is better solved with DI if you want to create an application with modularity or plugins?
Using the ASP.NET Core Application parts feature you can easily put your area's controllers/view components inside another project and then use in the main web application. It is a bit more difficult with the views and static content. I prefer to add them as resources in the same projects as area controllers are located and then implement the IFileProvider interface and assign my implementation to the IHostingEnvironment.WebRootFileProvider property.
You can use ExtCore framework to make this all automatically.
Hi so I'm a newb at cross platform stuff and I'm trying to figure out what MvvmCross brings to the table.
From my poor understanding, Xamarin already allows for everything except UI stuff to be written in csharp. Where does MvvmCross come in?
MvvmCross brings the MVVM pattern to platforms where it was previously unavailable, like iOS and Android.
It also supports data binding in Views. This is a powerful feature that provides great separation of concerns. The View will use the ViewModels to offer proper behaviors in the application. MvvmCross even locates the ViewModels in a dedicated project so you can easily reference and reuse them in others.
This is the most important point when talking about MvvmCross. By locating the ViewModels in a Portable Class Library (PCL), you can add them as a reference to any other projects. Of course, that’s not the only interesting point of MvvmCross. There’s also a plug-in architecture, dependency injection (DI) and more.
Source: https://msdn.microsoft.com/en-us/magazine/dn759442.aspx
Xamarin already allows for everything except UI stuff to be written in
csharp.
Xamarin allows you to write UI stuff in C#.
MVVMCross (Mvx) allows you to use the MVVM pattern in cross platform development, so that you can have a shared business logic layer, ViewModel. So you are creating different Views based on the platform but binding to the same ViewModel.
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
JavaFX with it's binding seems great technology for building UI layer, replacing PHP+AJAX, but are there any frameworks for building database forms applications with JavaFX, or it is meant to write everything from scratch?
You should give a try to some recent libraries :
JRebirth Application Framework to structure your whole application
http://www.jrebirth.org
FXForm to manage form
http://dooapp.github.com/FXForm2/
DataFX to manage complex tables etc..
http://www.javafxdata.org
You can find more tools at http://www.oracle.com/technetwork/java/javafx/community/3rd-party-1844355.html
Eric Bruno has a nice write up on JavaFX and Database using JavaFX Composer. See his articles at DrDobbs
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