Today i was doing a POC using MVVM Light Toolkit.
My Senoir asked why do we have to use MVVM light toolkit. He said we have to explain it to client that why do we want to use it.
I tried to suggest things like Built in classes for Commands ,Messages but i dont thinks it was strong enough.
What are the Pros and Cons of using this. Is it not good or its not flexible enough...
I would really appreciate of your help on this.... i know that application can be built without it as well so why to use a framework???
Money, money, money. Time is money. If you save time with toolkits that are free(or not free, but you can save the time to write them) you save money.
I think the same kind of question was asked few minutes ago
Custom MVVM implementation Vs. PRISM
Please, try to search just a bit before posting this kind of questions ;)
Recently, I've started working with WPF, and I'm asking a lot of what I think are basic questions about databinding. I don't 'get' it yet; why one thing works and not another (for seemingly voodoo reasons), how I accomplish what I want to do, and what everything means precisely.
There's lots of tutorials out there that go over the simple basics, but I can't find any that cover things similar to the more complicated examples that I'm trying to do. I don't want to create lots of toy apps, I want to understand what on earth is going on and what everything means. Where can I learn this?
Not knowing where you've already looked makes it a bit harder to recommend anything, but I started with two items on The Code Project, 1 from Josh Smith and 1 from Sacha Barber. From there, I read a lot of Josh's blog posts, and eventually bought WPF Unleashed.
Pick up a copy of Pro WPF in C# 2010
It is a question everyone who have been in your situation ask themselves, often with elevated blood pressure and frustrated jaw syndrome.
The answer is of course just to plow on, do it and do it some other way;
it's steep, but it's pretty fun, once you get over the most new-agy part of WPF in general,
and the design pattern adherence mental debate it very often leads to.
I find this cheat-sheet very useful: http://www.nbdtech.com/Free/WpfBinding.pdf
I've just written my first silverlight 3 app.
It's written using the code behind in a rater messy way.
I want to refactor into mvvm.
I'm finding it extremely difficult to find any tutorials on this.
So far from what I can gather I'll probably need a mvvm framework.
Mvvm-light toolkit sounds like it might be what I want, but I can't find a beginners tutorial.
This is actually more frustrating than I thought - do I actually need a framework?
Would I maybe be better just trying to do this from scratch with out a framework?
How did you get started with silverlight and mvvm?
Also I'm using vs2008 so silverlight 4 is a non starter for me.
Thanks in advance for any pointers.
I recommend you start with my session at MIX 2010 "Understanding the MVVM pattern". I go into the MVVM pattern as well as two important components of MVVM Light Toolkit: RelayCommand and Messenger. This should give you a head start.
Then, check the articles on http://www.galasoft.ch/mvvm/getstarted#tutorials
For the records, I am working with a member of the community to produce documentation aimed at beginners, but it takes time, and we do it on our free time.
If you have questions, ask on StackOverflow, but please tag with mvvm-light. I am monitoring this tag and do my best to help people with samples when I can.
Cheers,
Laurent
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 12 years ago.
This is a question I have had rattling around in my head for some time. I had a chat with a guy the other night who told me he would not be using the navigational framework because he could not figure out how it works with MVVM. As much as I tried to explain that patterns should be taken with a pinch of salt he would not listen.
My point is this, patterns are great when they solve some problem. Sometimes only part of the pattern solves a particular problem while the other parts of it cause different problems. The goal of any developer is to build a solid application using a combination of patterns know how and foresight.
I feel MVVM is becoming the one pattern to rule them all. As it is not directly supported by .Net some fancy business is needed to make it work. I feel that people are missing the point of the pattern, which is loosely coupled, testable code and instead jumping through hoops and missing out on great experiences trying to follow MVVM to the letter.
MVVM is great but I wish it came with a warning or disclaimer for newbies as my fear is people will shy away from silverlight development for fear of being smacked with the mvvm stick.
EDIT:
Can I just add as an edit, I use and agree with MVVM as a pattern I know when it is and isn't feasible in my projects. My issue is with the encompassing nature it is taking, as if it HAS to be used as part of development. It is being used as an integral feature and not a pattern, which it is.
EDIT 2: Thanks for all the comments so far, one issue that is surfacing from this is something I have not thought about until now. Is the introduction of richer more advanced frameworks for GUI/RIA development showing a weakness in RAD development for this generation. That is, is there a lack of code design and pattern knowledge being taught along with these frameworks? I once asked for a book on just C# (Before Pro C# & the .Net framework was popular) and was told why would I want to know C# minus winforms/asp.
Sure there are plenty of books/KB on these subjects but are people using them, beyond the superstars and very good programmers?
So, here's something that I think a lot of new MVVM developers forget - the pattern is there to help you, not the other way around. Building software in this manner tends to make your life easier as your project gets larger, but if it's completely getting in your way for a specific task, take a step back and ask, "In this specific scenario, is MVVM helping me here?" You're allowed to "cheat" a bit from time to time if it makes your life easier.
Actually I've used MVVM quite effectively with Navigation Applications with the Windows Phone 7 framework using commands and messaging. But if someone tells you that you can use every feature of Silverlight without adding some code to the code-behind, then they are fooling themselves. Use the pattern where it helps and make sense, and go "off-pattern" when a particular feature requires something custom.
Assuming your question applies to WPF as well, I sort of wonder if the problem isn't just the massive learning curve of WPF/Silverlight, before it even occurs to you to try out MVVM. Think about all the new things that need to be learned with WPF (and I assume Silverlight): XAML, dependency properties, attached properties, routed events, routed commands, static resources, dynamic resources, styles, data templates, control templates, databinding, etc., etc. etc. Then take the fact that Microsoft released this technology with an incomplete set of, at least with WPF, badly skinned controls, and you have a recipe for frustration and the inescapable feeling that you are dealing with a technology that is "not ready for prime time". I mean, before the WPF Toolkit came out, there wasn't even a proper DataGrid control.
Once you understand all these things, MVVM is yet another hurdle, but I don't think it's the main impediment to people jumping on the WPF/Silverlight bandwagon. That said, it would be nice if Microsoft would get behind it the way it has gotten behind ASP.NET MVC. As it stands today, you have to download and use third-party tools, like MVVM Foundation and MVVM Toolkit (which, incidentally, have a lot of overlap and should be combined into a single project).
So, I agree with you to a point, but I think most of the challenges involved with MVVM are probably due to the lack of support from Microsoft, and the inherent complexity of WPF/Silverlight, not due to any flaw in the MVVM pattern itself.
Great answers here, by the way. Good discussion and an important one to have. There is no doubt that learning Silverlight can be intimidating for new developers, and the MVVM framework will no doubt compound that.
However, I do agree that someone not understanding it isn't a dig against the framework. I still have developers who tell me that inversion of control/dependency injection is too confusing to learn, but does that make these invalid patterns? The fact the so much proven, "in the field" software relies on those concepts tells me they are sound even if complicated to grasp at first or understand.
Then again, learning a foreign was tough when I started, but once I pushed through, now I can speak it comfortable and wonder why it was so hard to begin with.
I guess the trend that scares me the most is this notion that for some reason complicated, enterprise applications should be easily built by beginner developers who either can't or won't grasp complex concepts. That's what it really boils down to. You don't have doctors saying, "Help, make this brain surgery easier so any one can do it." It's specialized. Building great software is also specialized, that's why consultants command good payment for their services: it's the value they provide in understanding the right way to architect and develop solutions.
If you are making an asteroids game, a fantasy game, a media site, a YouTube knock-off, etc, then you probably don't need MVVM and it is overkill. If you are building a small site with a few forms and graphs then build it how you are comfortable and be done with it.
If you are building a large, complex site that is composed of multiple, dynamic modules, moves thousands or millions of records and requires scaling to massive concurrent users, then you can't expect the design to just pop out after thumbing a few pages of a book or skimming a few sites. Software like that is complicated, with a lot of moving parts, and rqeuires a firm grasp of architecture.
What amazes me is people presumably building these more complex applications who still don't get building these more complex applications. Is there someone experienced on the team? Do you have an architect to stub out the framework that you can consume?
I mean really, the example just tells me the problem isn't MVVM, it's the developer. "Avoiding Navigation because of MVVM?" REALLY? What's MVVM got to do with it? Write the navigation pieces, and let the view models live inside the pages. Why does my navigation have to drive from a view model?
Come one. If it's that complicated I think it has nothing to do with the pattern, and everything to do with the developer just not understanding development. Don't blame the pattern. Maybe they need to stick to simpler applications. In my experience, people who come to understand the pattern understand software well enough that they know when and when not to use the pattern.
I know there are many movements to boil it down and make it simple for the "average consumer" but I think this is like trying to say, "Calculus is the wrong way to find the area under a curve because it's too tough to learn." While MVVM isn't as complex as Calculus, building complex software is a complex endeavor and I don't think you are ever going to simplify it or boil it down to a simple formula (nor should you). If you struggle with MVVM, please, don't use it - find something simpler and easier. If your project is complex enough to use it and you still don't grasp it, please hire someone who does, have them plumb it out and learn from them.
No, I don't want Microsoft telling me what pattern to use nor do I feel it is their responsibility. I'm a professional and it's on my shoulders to invest the time to learn and understand what I'm building so I can build it the best way for the customer. Microsoft doesn't necessarily know what my customer does or needs, so how can they possibly tell me what pattern to use? Projects like Prism are great because they are a compromise: they provide guidance and share "best practices" of how something can be done, without forcing that implementation on the developer.
I'm using MVVM for a Windows Phone 7 app. I really like the idea of it but there's too many hacks, wordarounds and 3rd party tools needed to get it running.
Things are getting better with every release of Silverlight but I still think the technology is "bleeding edge".
Why can't you?
And no, MVVM is just one of many patterns and frankly, not even amongst the most popular ones. What is hurting Silverlight's development is a) Flash b) not being Flash c) being Microsoft centric d) learning curve.
Plus the fact WPF doesn't really seem to have caught on doesn't much help.
Someone has problems figuring out how to use navigational framework with MVVM => Someone doesn't use navigational framework => MVVM is killing navigational framework => MVVM is killing Silverlight development.
Would you say there are few flaws with this chain of reasoning?
For a developpeur who as to do a project with WPF or Silverlight (xaml code), is it trial to learn some design (basics) and to handle blend? Beacause in France there isn't much blend professional (compare to photoshop users) and the price/day of a blend designer is very high.
What I am sure is there i ain't no artist, but it could be interesting/fun to learn something that different then pure code. So my question is mainly for designer or developpers that had to learn some design, is it that hard for a custom design?
The principle of design are not difficult to learn but they're not always easy to put into practice and that's why it's considered an art rather than a skill. Certainly WPF/Silverlight is a designers dream as far as desktop UI is concerned since it's VERY flexible so you'll find few restrictions on what is possible when compared to other technologies. Blend works well with them too and it's not that tough to learn.
To start learning design as a developer, i'd suggest you take in as much material as possible and pratice,..a LOT. Read design blogs like the ones here and read plenty of books. Some good starter books are The Non Designers Design Book, The Design Of Everyday Things and Don't Make Me Think. I know they all really help when i started to look into UI and interaction design.
Hope that helps.
A great way to find your way in the design world is the Principles of Design Series on Microsoft Showcase. These videos explain things like Rythm and Unity.
There are a lot of other videos that should help to find your way around Expression Blend and Silverlight.
One thing that works for me all the time is to look what others do and use that for inspiration in you own design. Just google-image or bing-image for you are designing or see if it is in the Infragistics UX explorer.
I understand your question as I went through the same thing. I've done plenty of web sites over the years, but I never felt as though they had the "zing" a good graphic artist could provide. Because of this, I had concluded some time ago that to really take my skills to the next level I had to learn at least some graphic design, but I never did anything about it.
That changed when I started learning WPF. I quickly decided that I needed to learn some basics, especially when I started using Blend which was a whole new world after living in Visual Studio for so long.
To jump start my graphic artist education, I took an introductory course at our local community college. It was worth every penny: I was exposed to principles of design and some key software products like Adobe Photoshop and Illustrator. Understanding them made Blend finally "click" for me. The experience has proven invaluable to me as a WPF developer, and I would recommend it to anyone interested in UI work.
WPF Silverlight have a lot of power however even when mastered it takes a lot of time to design a simple form say using a tab control using lots of grids with rows and columns and stack panels than it would on a normal desktop. Also it can be quite sloppy looking back at the XAML code just from a design point of view unless your using lots of windows which i try to avoid, i would rather have a tab control with each tab acting a a window. Anyway from a design point of view it is much more time consuming than a desktop application. You will find a lot of developers will use it as they are not good in code behind. So it depends on the program you are writing. ?You can make your program look very good from default controls and the listview is always a great control. Many will disagree because they think they are great developers and most likely will talk the usual no one want's to hear!