As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I learning WPF MVVM pattern for couple of weeks already.
I still don't have clear understanding of this pattern.
I've read this topic https://stackoverflow.com/questions/275098/what-applications-could-i-study-to-understand-datamodel-view-viewmodel and almost all referenced articles.
The problem with all examples is that they have "a lot of extra stuff" (menus, several views etc. etc.) It's good when you need to learn how to do complex things, but it is not good when you looking for something you can start with.
I would like to have an application which I can use as skeleton to build my own application. I.e. I would like to see an application which has only absolutely mandatory things, that would be I suppose:
Main window
Model class
ViewModel class
View class
some ICommand implementation? (am I need something like that)?
probably I'm missing something
Part of the problem is, if you think about it, most of these aren't anything specific.
If you want only the "pure requirements", pretty much the only thing you'll need is some ICommand implementation. This is because the following are just standard WPF or C# classes:
Main Window -> Just use a Window
Model class -> This is your normal project data. Shouldn't be changed for MVVM
ViewModel class -> This is just a normal C# class that implements INotifyPropertyChanged
View class -> Standard WPF UserControl
The only thing you kind of need is an ICommand implementation that routes delegates to an ICommand. This can be ripped out of any MVVM framework (they all have at least one, but usually two implementations, one for Action and one for Action<T>, where the argument is routed from CommandParameter).
If you need a simple implementation of the command, you're welcome to steal the one from the code of my MVVM Series. The code for it isn't trying to be a "framework", since the goal was to show just the basics of MVVM.
Check out this video by Jason Dollinger on MVVM. It's a small example that goes through the process of creating a non-ideal implementation, and then how to do it properly using MVVM. I found it very useful when starting out on MVVM. I thought the video was solid enough that I didn't even need to look at the source, but that is available as well.
look at this cool toolkit
MVVM Light Toolkit
http://www.galasoft.ch/mvvm/
I wrote a very basic MVVM example here if you're interested.
When I first started learning MVVM I had the same problem you did... I couldn't find any simple resources to explain the very basics of MVVM. It was even harder when I was trying to explain the MVVM design pattern to someone else, so this was a sample app I put together for him. I thought it was fairly simple and straightforward, so posted it online.
Edit: The actual "MVVM skeleton" I usually use looks more like the code found in this link. The first link was an extremely mvvm simple app with a single page, however the 2nd one starts with an AppViewModel which can handle switching Views.
Related
I'm just learning the ropes of the MVVM pattern in WPF applications, and I can imagine that this sounds like an incredibly stupid question, but here goes anyway:
I already have a model in one assembly, which is a simple class library. In a different assembly, I've created a simple view in xaml. Now the books all tell the same: link them together with a viewmodel. My question is though, where does this viewmodel belong:
Is it more or less part of the view, and should it be in that assembly?
Is the viewmodel meant to be universal, so it belongs together with the model assembly?
Does the viewmodel get its own assembly?
I know the MVVM pattern is merely a design guideline and not a strict set of rules, but I feel it's better to learn things the right way.
EDIT
Follow-up question: is a viewmodel meant to be re-usable? I can imagine a scenario where it would be usefull if you could use the same viewmodel for a WPF desktop application and a silverlight web application.
It facilitates building the view, so it belongs in the view assembly.
Think of it like this: could you take your model assembly and use it in a different style of application, e.g. a Windows service or a web application? Is there anything that is irrelevant to that style of application in that assembly? If the answers are yes and no, you've built yourself a useful re-usable component that is independent of the type of user interface.
Depending on the size of the project, I put the ViewModels either in the same assembly as the views, or in their own assembly, but never in the model assembly. The model shouldn't contain anything related to the UI.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Okay, to give a little background, I learned WPF about 3 years ago and have kept reasonably up to date with what's happened since in various different versions. I looked at (and implemented) MVVM on a couple of projects, had a good look at frameworks like Prism so I think I'm pretty well versed in most areas of the framework. I've also worked briefly on a couple of small Silverlight 2.0 projects.
My problem is this, I'm about to start a Silverlight job at a new company and while I'm very comfortable that I can do the job well, I feel like my WPF knowledge may cause me some issues. I've gone over the WPF/Silverlight guidance white-paper on codeplex which is excellent and really helpful but although it highlights the differences that still leaves me wondering how to get around those differences.
For example, I know that DataTriggers are missing as areMultiBindings and a whole array of other stuff. What I'm interested in reading about is not the differences per se but how you get aronud those differences or what other patterns are useful in Silverlight. What if I need a DataTrigger? clearly my design should take these things into account.
So, the question is,..if you've gone through this transition, what differences caused you the most trouble and how did you get around it?
First, while this is dated to Silverlight 3, this white paper goes through the differences between WPF and Silverlight in detail:
Microsoft WPF-Silverlight Differences White Paper
http://wpfslguidance.codeplex.com/releases/view/30311
That is a great first step to familiarize yourself with the differences.
You might also want to take a look at the Prism project. One of the goals of this project is to build a set of interoperable functionality between Silverlight and WPF so you can essentially build enterprise applications that target both platforms and reuse the majority of code. Familiarizing yourself with the project will help highlight differences as well:
http://compositewpf.codeplex.com/
Finally, while Silverlight might not have data triggers, you can use a combination of features such as behaviors and triggers:
http://www.silverlightshow.net/items/Behaviors-and-Triggers-in-Silverlight-3.aspx
And the Visual State Manager (VSM):
http://timheuer.com/blog/archive/2008/06/04/silverlight-introduces-visual-state-manager-vsm.aspx
To accomplish most of what you need.
Giving a Silverlight port per se for our WPF App, the following are the two 'pain' points we encountered.
Splitting up and grouping XAML's/modules for improved performance and on demand XAP downloading using MEF.
Challenge of achieving Binary Compatibility using the same code base for WPF/Silverlight.
A few of our Functionality required OOB and user acceptance.
We optimized a bit of Functionality relying on IsolatedStorage.
Hope this helps.
[ Now that Silverlight 4.0 has a stable build, we had a few Visual Studio hiccups over the last few releases which resolved itself overtime. (We stuck to Silverlight 3.0 and somewhere in mid march jumped to SL 4.0 beta and final release)].
N.B. : I have tried to keep things way abstract to not reveal the identity of the client.
MarkupExtension
IMultiValueConverter
Template.Triggers
Style.Triggers
Binding RelativeSource={RelativeSource AncestorType...
Binding.IsAsync
{x:Static ...
{DynamicResource...
Grid.IsSharedSizeScope / SharedSizeGroup
All of these are not supported in Silverlight and you have to workaround them.
Every case needs it's own judgment about how to "fill the gaps"
For the triggers part, the only solution is to use VisualStateManger.
The following article gives a good example of how to make the transition from triggers to VSM: http://blogs.msdn.com/b/wpfsdk/archive/2009/02/27/the-visualstatemanager-and-triggers.aspx
Next, OnApplyTemplate is fired in different order, which might affect any Custom Controls or UserControls you might have created.
WPF:
UserControl Constructor
MyControl Constructor
MyControl.OnApplyTemplate
UserControl Loaded
MyControl Loaded
Silverlight:
UserControl Constructor
MyControl Constructor
MyControl Loaded
UserControl Loaded
MyControl.OnApplyTemplate
And of course Microsoft has an article about that, called "WPF Compatibility" and gives a more thorough overview about the differences and changes between WPF and Silverlight:
http://msdn.microsoft.com/en-us/library/cc903925(VS.95).aspx
Hope this helps
Silverlight forces you to make some changes to your design patterns, which, if is pervasive throughout your software, can render code reuse quite moot.
For instance, data template selectors are missing -- I found this to be quite a shock.
The Silverlight(& WPF) space seems to have a whole new nomenclature around it so at times I'm having a hard time figuring our what is important and useful to research a bit more.
For example I 'know' about the MVVM pattern but I'm looking for things that are a bit smaller in scope, that is topics, ideas, programming constructs that might be used in implementing MVVM and would need to know before hand.
So basically I'm looking for some of the key topics and concepts that people have found useful or are important when creating a Silverlight apps. And maybe why it is useful or important and when\where it might be applied or used.
Thanks.
If you are a newcomer, don't bother with MVVM yet. It could easily overcomplicate everything.
I recommend you to build your first one or two applications without it.
(See this question.)
The concepts you should get yourself familiar with:
XAML syntax and the concept of code behind
Styles and Templates
What UIElement, FrameworkElement, Shape, Control, and other abstract classes are
Bindings (there are quite a few types of them)
How to create custom controls and styles for them (In SL, generic.xaml)
If you feel familiar with the above (and you feel comfortable with XAML, or someone in your team already does), read Silverlight and WPF best practices and then you can get started with MVVM.
I find the two most important things to learn to fully utilize WPF/Silverlight are first Data Binding and second the Templating model. Data Binding is key to many applications, but IMO Templating is where WPF/Silverlight really shines.
I might suggest you start by widening your scope to include WPF as well since in many cases the design patterns and coding patterns overlap somewhat. Obviously Silverlight is a slimmed down version of WPF but since many of the methods and styles of design are similar it may help to look at some WPF practices as well.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are the top 3 main concepts in WPF that you need to understand in order to write good WPF code?
I think the most important aspects of WPF concepts are:
Templates and Styles (the way you define the behaviour and appearance of your application)
Data Binding (the way you should glue together your UI with your business objects
Declarative UI definition through XAML
Maybe there are other elements but in my opinion those are fundamental for WPF thinking.
I would say the single most important concept is the UI pattern Model-View-ViewModel, or as I like to call Model-View-ModelController. This is crucial to building apps successfully in WPF. Besides that, the real conerstones are Databinding, Templating, and Styles as others have mentioned. There is a nice post here on some common pitfalls to avoid when developing in wpf.
The real basics that you have to grok is:
XAML
Layout
Content model
Data binding
Their are loads more but these are the ones that has changed the most from winforms...
Also check out this thread: Interview questions: WPF Developer
I duno about top 3 but Attached/Dependency properties is pretty important.
I can only think of two big main concepts in WPF
In no particular order:
Bindings
Templating and Styles
When you have learned those two concepts, you will be able to write decent WPF code...
Oh, and the third would be XAML.. but that is the language... however, you might want to try to put as little in the code behind and as much in your XAML file...
Its quite easy to choose the code behind approach, but try to do it in XAML in stead...
The most concept in WPF lies on the stype and the behavior of the UI. It has lot of features, among them the following three are the most useful and important aspect.
Building the data binding of the business object and UI.
Changing style and more user friendly as to easy implement in UI so that the look and fill is good as user perspective.
Redefining the UI through the XAML and changing the font, style, implementing animation etc.
So its most powerful concept.
To know more about the technology, one should know about the architecture of a technology. However following are the basic but most important concepts in WPF are -
1) XAML
2) Rich Layout, Panels and Windows
3) Content model
4) Data binding
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This question intends to provide a list of solutions to common pitfalls, "gotcha's", or design issues when developing WPF applications. This can also include proper design-patterns as long as there is an explanation as to why it works best. Responses should be voted up or down based on how common the type of issue is. Here are the rules:
One response per post. This will clearly give the most common issues the highest ranking.
It would be best to provide the link to the a related post or solution already living somewhere in SO land.
Problem : The major issue I have seen so far is that people start coding in WPF with the winform UI model in mind.
Solution: WPF is not WinForms/MFC/Win32 So Forget all the UI side assumptions and norms you have used and learned while developing Windows based UI for last 20+ years.
It is very important to understand the core ideas behind this platform, This link- Major UI Development Breakthroughs in the new WPF platform will give an in depth view of WPF. Which lists out the following points. The highlighted ones are my favorite features of this platform.
Advanced Graphics
Drawing Object Model
Rich Application Text
Adaptable UI Layout
Flexible Content Model
Lookless Controls
Data-Driven UI
Consistent Styles
Triggers
Declarative Programming
Not realising how bad the font rendering is at the start of a project and being told by the client they can't stand looking at it because of how fuzzy everything looks.
Problem: Using the M-V-VM design pattern, where do I instantiate the views? Does this happen in the ViewModel? SO Question 1, SO Question 2
Solution: WPF development is most effective when using the M-V-VM pattern as opposed to other common patterns such as M-V-C. The tendency is to treat the ViewModel the same as you would the controller which would handle opening and creating views as well as the models. This is not the case in M-V-VM. Views are the only place where are the views should be created. The ViewModels should know nothing of the view. SO Answer 1, SO Answer 2
Problem/Question: SO Question
How do I expose a DependencyProperty
of a component in my user
control to users? There are plenty
of examples of how to expose a normal
property by creating a new dependency
property and binding, but none on how
to expose a read-only property like
FrameworkElement.ActualWidthProperty.
Solution: You need to expose a new Readonly DependencyProperty in your user control, and update it whenever your contained "component"'s ActualWidthProperty gets updated. This requires using DependecyPropertyDescriptor to get notified of changes that occur. SO Solution
Getting data binding to work properly between properties defined in ContentControls (Windows, UserControls, etc..) and properties on elements that make up the controls content. For example. Let's say I have a Window that looks like this:
<Window x:Name="MyWindow"....>
<TextBlock Text="{Binding Path=PropertyDefinedInMyWindow}" />
</Window>
Problem: No matter how often you update the "PropertyDefinedInMyWindow" it never gets reflected in the TextBlock. SO Question
Solution: You need to set the DataContext of the Window or tell the binding which element the property lives on. SO Solution
Ivan Towlson did a really good presentation on this topic. Most of the information is in his slides, which you can get from here:
http://hestia.typepad.com/flatlander/2008/08/codecamp-2008-.html
Using code - behind in views, which makes baby FSM cry.