We're just starting up a new (our first) Silverlight project where we want to make a back office silverlight application using MVVM. Our application will need navigation through some kind of menu UI.
I've been poking around the web finding various frameworks (Galasoft MVVM Light Toolkit / Silverlight.FX / Prism) to help with building a MVVM application but i find it hard to single out which one suits our needs the best.
Does anyone have any experience/tips on which one to pick for a larger application with many Views and navigation between them.
Also, is a navigation Application the best way to get a "framed" application (with navigation inside the frame) or is there a better way?
I'll throw in a vote for Prism/Composite Application Guidance...mainly because I've used it in a number of "for work" projects.
The modularity stuff is great - you basically code up individual projects as if they were miniature applications in their own right, and you rely on the region management paradigm to composite your multiple "modules" into one cohesive app.
It does get a bit annoying as the module count gets high, although you don't have to make each module its own project...
Take a look at this article written by Jeremy Likness. He is using Prism and Navigation framework and its a good article to get you going with. Its also not hard to take the sample he provides and apply some MVVM principles to it.
Related
I've been looking into adopting MvvmCross in developing our next generation of software, mainly with the aim of developing tablet UIs for it. I understand that MvvmCross does not currently support WPF but I can see ourselves developing that and contributing it back.
However, I've also noticed that MvvmCross seems to be very light weight in that there is little support for composite UI as described in the Prism guide.
Unfortunately, we do need to allow for more complex composited UI scenarios.
Given what is stated in https://stackoverflow.com/questions/10224376/mvvmcross-experiences-hindsight-limitations about forking or rolling your own with MvvmCross as a reference, and given that we do need more complex UI scenarios than those that MvvmCross provides, what would the best course of action be, fork and reimplement the parts of prism we need, try to get MvvmCross to work together with Prism as is, or develop our own from the inspiration of MvvmCross and MonoCross?
Update: See Second answer below...
I might need to write a longer answer to this tomorrow...
As an initial answer:
someone has already done a port of MvvmCross to Silverlight and the developers have suggested this might become available to the wider community
the PCL version of MvvmCross should be quite straight-forward to port to WPF - although possibly not if older .Net Runtime versions are required
as the chief dev of MvvmCross to date, I'm personally interested in supporting WPF - especially right now for my project http://github.com/slodge/BallControl which needs a desktop to run in (Windows Store is crippled - pah!)
composite UIs are supported in MvvmCross - e.g. tabs, pivots, panoramas, splits, modal children, etc - but there's not much work been done yet on a full composite UI like often seen in Prism.
I have seen people combine MvvmCross with other IoC frameworks, but (no work that I know of) has been done to date on combining MvvmCross with MEF (which is often used with Prism?)
If I were tackling this problem area, then I'd come at this:
Make sure we try to get a working app out first and foremost - the app matters more than the framework.
For framework, I'd try porting the basic IoC setup across first and some simple navigation
For the custom navigation (for displaying UIs in regions) I'd look at the role of the Presenter in MvvmCross - this is what I use in Tab examples, in iPad split view examples, etc to provide complex UI features.
If this custom navigation isn't enough I'd look at how it might be changed/replaced/extended - my guess is that the genuine requirements for WPF/Prism will actually be quite similar to the genuine requirements for bigger iPad, Surface and Nexus tablet apps.
I'd try to keep everything modular and optional so that small phone apps don't have to pull in big navigation processes that bigger apps might need. The downside of this might be lots of projects and DLLs!
I'd also be open to this splitting into separate project(s) - much of the modern software world is ruled by small targetted apps rather than bigger, sprawling frameworks.
Because I'm part time on Mvx, and this is your full time job, I'd definitely recommend you don't let Mvx hold you back!
My initial reaction is 'yes, I'd be really interested in working on this' - the downside (as above) is that I'm only spare time on mvx....
Here's the second answer...
I took the WinRT version of MvvmCross as a base (but also used elements of Console, WP7, Touch and Droid too)
I produced a simple WPF version of MvvmCross - https://github.com/slodge/MvvmCross/tree/vnext/Cirrious/Cirrious.MvvmCross.Wpf
The main feature of this version is that it doesn't contain much in the way of navigation
e.g. don't try calling Back!
e.g. the main presenter is left abstract for the application UI to implement - see https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Wpf/Views/MvxWpfViewPresenter.cs
I then took the TwitterSearch demo app - https://github.com/slodge/MvvmCross/tree/vnext/Sample%20-%20TwitterSearch/TwitterSearch.UI.Wpf
created some simple views (using cut and paste of Xaml from WP7 version)
created a simple Region based presenter - see how RegionAttribute is used in https://github.com/slodge/MvvmCross/blob/vnext/Sample%20-%20TwitterSearch/TwitterSearch.UI.Wpf/MultiRegionPresenter.cs and in https://github.com/slodge/MvvmCross/blob/vnext/Sample%20-%20TwitterSearch/TwitterSearch.UI.Wpf/MainWindow.xaml.cs
that was kind of it... give or take a couple of hours of debugging
There's a video of this in action - with some explanation at: http://youtu.be/pYkLxqpu_5E
This is obviously only a first step in Wpf support, but I suspect it is already going to satisfy quite a few use cases... Please feel free to fork the source tree and to extend or replace this first attempt. Also, if it doesn't work for you, then feel free to abandon it and try something else instead.
I will try to work on this more - but can't really prioritise it above paid work... but I am open to being paid to work on mvvmcross too :)
Seeing as how MVVM is being highly regarded as a good system design pattern, I thought I might just jump aboard and give MVVM a shot.
Just a little background about myself before I begin with questions:
I have done a few years of development with ASP.NET Webforms. I have also done a fair bit of development in ASP.NET MVC, which I am quite comfortable with.
Currently, we have a number of "backbone" applications written using ASP.NET MVC 3 which we customize and sell to our clients whenever we're approached. These applications are all meant for internal use, hence plug-ins wouldn't be much of a problem.
The real problem with development is that for large scale business applications with complex business rules, ASP.NET MVC tends to slow us down (writing jQuery / javascript > server side processing > return result, use jQuery to notify > alter view, something along this line).
Then I began looking for answers that will help us improve our time to delivery and also responsiveness (well, we all know how JavaScript is capable of killing us) and my search brought me to Silverlight (we have the time to change, no worries there).
So here comes the questions:
I have come across many Silverlight MVVM samples online, but all of them show applications as simple as interacting with only one Database table. Is MVVM pattern well suited for large applications?
In MVC, I'm used to Dependency Injection from Ninject to pass an implementation of UnitOfWork to my Controller. In all samples I found online, none of them use any form of DI. Is it really unnecessary? Since the idea of MVVM is to decouple, so why not also decouple ViewModel from Model?
I've gone through a book published by Jeremy Likness called Designing Silverlight Business Applications. He used MEF to do the decoupling, which I think doesn't really fit into our application. We do not really need to do "hot-plugging". What's your take on this?
MVVM is all about Commands, Databindings and No Code-behinds. What if I want to interact with UIs that do not expose to commands? (I'm not too sure about this, I'm guessing ListView OnSelectionChange?)
To add to the previous answer:
We are developing a large corporate-wide Silverlight platform and a set of applications using MVVM. Seems to be working pretty well.
We are using DI extensively. Our system is built on top of Prism. Prism contains a large amount of sample applications of various complexity illustrating the use of DI in MVVM.
We use Unity as our IoC container. Prism contains guidance for both MEF and Unity. Unity seems to be a more traditional IoC approach.
In the vast majority of cases using Bindings and Commands covered our needs. For the others we use Expression Triggers and Actions. You can also create custom Triggers/Actions if necessary.
I have no answers for all your answers (never used MEF) but I can tell you my experience:
1- I've been in the development of a quite-large silverlight application and MVVM fits perfect to have a maintainable application. The bigger problems we had because of application size were because of Silverlight, not MVVM 8-)
2- I haven't used it too much but it's useful in many cases. There are several toolkits to use DI with Silverlight like MVVM Light Toolkit:
http://compiledexperience.com/blog/posts/blendable-mvvm-dependency-injection-and-unit-testing
4- For interaction between UIs you can use the Mediator pattern. The same MVVM Light Toolkit has a Messenger to subscribe, send and receive messages and maitain every layer decoupled.
Hope this helps you ;-)
We have lots of project developed using .net 2.0 version if I want to convert those project to WPF then what will be the approach. Please discuss in detail.
to let the migration to WPF easy, be sure that your existing code doesnt contains a high coupling between GUI and your Business layer, if it's the case the most important step is to refactor your existing code, so your GUI code will contains only what's related to GUI.
And after this step the part of your project to migrate will be not the big one, it will concerns only the GUI logic.
When I did this kind of migration from winform to WPF , we spent more time to remove coupling between GUI and other layers than to migrate the GUI layer, due to high coupling betwn GUI and other layers.
Having gone through a similar exercise I'll tell you that it can be done but there are some challenges.
Step1: Just for clarification when we say WPF some people mean Silvelright / web. WPF is not Silverlight so you need to clarify I want to migrate existing applicaitons to WPF thick client applications. Since you stated WPF I am assuming you mean thich client/windows based applications so we'll go that route. (I'll mention SL at the end)
Step 2: Evaluate your projects from the code level for the most part refactoring the code is fairly easy. Since you are migrating from .net 2.0 to .net 4.0 I would really look at how many of your classes are defined, and see what can be refactored or in some isntances completely redesigned. THis leads us directly into step 3.
Step 3: Pick a design pattern. One of the tricky parts is coming to terms with a new design patterns such as MVVM for WPF. More than lilkely you will want to strip out and redesign the entire UI. As a result you will also want to utilize a proper design pattern (MVVM) or some flavor of that. This will also tie back to step two as some of your code will need to change to support your design pattern.
There are a ton of resources online for MVVM as well as UI development. If you are looking for reading materials I would look to WPF 4 unleashed as well as WPF illustrated. Both are good reads to help you get up to speed on the UI components how they work and the proper approach to using them in a project.
Get familar with .net 4 and the use of collections, types and of course the numerous new classes for wpf.
Disclaimer: You can in many instances create a WPF application usign tradition winform layout and practices. Whether this is right or wrong is a matter of opion of the developer. My personal opinion is that yes you can forego learning new design patterns and use a winform approach but you will not gain the full benefit and capabilities of the framework using this approach.
And finally if you are planning to migrate these apps to the web (silverlight) your work will be a little more of a challenge. Silvelright does have a little higer learning curve and there are a few more rules (security, asynchronous calls, web services etc) that must be learned, and followed. I have foudn that in creating a migration that it is easier to migrate from Siverlight to WPF that vice versa. As Microsoft continues to improve Sivelright I think we will get to the point to where the code is interchangeable between the two patterns however right now it's not there.
Conduct a search online but here are a few links to help you get started:
Scott Guthrie (Silverlight) http://weblogs.asp.net/scottgu/default.aspx
Josh Smith (WPF MVVM) http://joshsmithonwpf.wordpress.com/
best of luck
Is using WPF navigation in standalone applications is best practice? And can it be used with WPF MVVM pattern?
To answer your second question, yes, WPF navigation can be used quite successfully with the MVVM pattern.
As far as the first question goes, the best answer is 'it depends'. Specifically, it depends on the application you are trying to create; some applications are logically 'navigation' applications, where the users are expected to navigate through a series of screens in some fashion, while other applications have different paradigms. The best advice I can give you is not to fight it - if your application makes sense in a navigation context, then by all means use WPF navigation, but if it doesn't then do not try to shoehorn it into one.
Perhaps the best way to determine whether or not your application uses a navigation paradigm is whether or not a back button makes sense; if it does, then you'll want to use Frame or NavigationWindow so that you can use the built-in WPF navigation support.
I don't think that System.Windows.Navigation is ready for production applications yet. I've found that using it in a WPF4 application is a frustrating experience if you need to pass data between pages.
I also encountered a serious bug that causes databinding to fail after using back or forward navigation.
Numerous WPF toolkits and frameworks exist for MVVM, MVC and MVP style applications. Virtually all of them replace the Hyperlink, Page, Frame and Journal classes that Microsoft provides with custom-built navigation services. So the developer community appears to have given System.Windows.Navigation a "vote of no confidence".
Hopefully support for navigation-style apps will improve in the future.
If you have an application that's suited to the navigation metaphor, it's probably worth investigating these alternative frameworks. (Of course, these toolkits have their own learning curve associated with them.)
I'm still searching for a good approach to this problem myself.
Couple of year ago I when to work for company as web developer. It has my first Sirius web development job, (ASPx/C#) so it has very exciting and I learned a lot about that world, from the developer point of view.
In that group we had a concept for the pages where loaded in the page UC’s (User controls), I don’t know if it’s the same in every web development team with every language, I’ll assume it is so.
The contract ended and I came back to develop win32 “winForm” application.
But since them I have tried to apply the same principle for my win32 development I learn there, meaning having bunch of UC’s (Visual User controls) that I load in the form.
They are regular visual components, not loaded in the toolbox, code is available in the project, but the component is not developed in the form, they are loaded there.
I would like to know opinions about this approach, what other are doing similar or better to this And improvements that can help us to speed up development and increase code reuse, because that is what this is all about.
If you're using the layout components in Winforms, this might be an acceptable approach although I think the thing that distinguishes the web and Windows Forms (note: NOT WPF!) is that in the former you do a lot of "compositing" which is why the UserControl concept is so useful whereas in the latter you operate on very sophisticated controls (e.g. 3rd party - in my last gig we used an incredible grid control via a small company called Infralution)
The main problem I would see is with layouts since the rendering model is a little different than the web. I know nothing about your application but if it "works" that is what is most important. I assume in this case you use things like the FlowLayoutPanel and the TableLayoutPanel properly.
If you want to go a more canonical route, take a look beyond simply creating components at how you can use the inheritance model to composite your application in a more robust way - having a base Form class that has containers for where your "UserControl" type components go and then using some kind of interface based dependency injection to swap them out while the application is running.
Finally, take a look at some of the open source Windows Forms applications out there to see if you're being too hard on yourself since common UI and reusable components are a goal in every application. Even though I've always thought Microsoft's Patterns & Practices stuff teetered towards being bloated, there are some good ideas and you should study some of the approaches of the Composite UI Application Block they put out.
Okay, not finally, there's one more thing I'd like to add: take a long hard look at WPF which will bring back a lot of the concepts from your web development days and give you that kind of power in a desktop application.