I have recently been trying to learn about MVVM and all of the associated concepts such as repositories, mediators, data access. I made a decision that I would not use any frameworks for this so that I could gain a better understanding of how everything worked. I’m beginning to wonder if that was the best idea because I have hit some problems which I am not able to solve, even with the help of Stack Overflow!

Writing from scratch
I still feel that you have a much better understanding of something when you have been in the guts of it than if you were at a higher level. The other side of that coin is that you are in the guts of something that you don't fully understand which will lead to bad design decisions. This then makes it hard to get help because you will create unusual scenarios which are less likely to occur when you working within the confines of a framework.

I have found that there are plenty of tutorials on the basics of a concept but very few that take you all the way from novice to expert. Maybe I should be looking at a book for this?

Using frameworks
The biggest motivation for me to use frameworks is that they are much more likely to be used in the workplace than a custom rolled solution. This can be quite a benefit when starting a new job if it's one less thing you have to learn.

I feel that there is much better support for a framework than a custom solution which makes sense; many more people are using the framework than the solution that you created. The level of help is much wider as well, from basic questions to really specific, detailed questions.

I would be interested to hear other people's views on this. When you are learning something new, should you/do you use frameworks or not? Why? If it's a combination of both, when do you stop one and move on to the other?


Use a framework.

  • It's always good to be able to add a publicly used framework to your resume
  • You actually get stuff done rather than focusing on plumbing implementations
  • You gain insight into how others do it. More cases than not, they have more experience than you, so you may learn new things that you otherwise never would have thought of
  • If you still want to learn the internals, step through library code with your debugger. Enhance it (if it's OS) and provide patches to the author(s) if you think what you've written is useful.

In short, using a framework will always get you up to speed with a design pattern than rolling your own. Even if it's an academic exercise, the insight that you gain when using another framework (or a number of them) is invaluable.

There's no sense in rebuilding the wheel when there are a number of them already built, with solid documentation to help you in learning the specific patterns.

However, if you have specific requirements that aren't met by something that's already been written, then that's another story altogether.

  • The killer comment for me was "It's always good to be able to add a publicly used framework to your resume" which is something I hadn't thought of. Of course, using a framework doesn't mean that you can't see how things work, thank you for pointing that out. – Stuart Leyland-Cole Jun 3 '11 at 15:28

I sometimes take a hybrid approach. First, attempt to write it from scratch, but don't get too attached to your implementation. Once I begin to get a decent understanding of the problem scope, I often discover a new appreciation and understanding of the frameworks that exist, and better insight into which frameworks fits best. I often will just hit the eject button mid-way through it and go with the framework that fits best.

Once in a while, I discover that none of the frameworks are exactly what I need maybe the following reasons:

  • High overhead and/or performance characteristics
  • Lack of features without extensibility
  • Too much complexity (either in the code or in configuration)
  • Licensing model

In these cases, I keep going. Sometimes I still discover that the problem scope becomes far more complex than what I'm willing to spend the time on, and then I reevaluate.

It's not the fastest get-it-done approach, but it's worked out reasonably well for me.

  • 2
    This is exactly what I was going to answer. After I've gotten a way into my own implementation I can really grok a framework because everything is "so how do they do this ... ah, right!". I wouldn't do this for everything but I have done it more than once and found it rewarding. – Jeremy Jun 2 '11 at 0:10
  • This is a rather sensible line to take and I think the key part is deciding when you have learnt enough to move on to the frameworks. Also having that mindset that you are going to dump your work is a good place to be at the start rather than figuring it out halfway through. By that time you are probably too attached to your code to let it go. – Stuart Leyland-Cole Jun 3 '11 at 15:31

I used to try and do everything from scratch, but I am discovering that using an existing, widely accepted frameworks is a faster way to learn.

It is far easier and faster to view a correct way of doing something and picking it apart to understand it, than it is to figure out how to do something (often incorrectly) through trial and error.

For MVVM I would recommend looking into Galasoft's MVVM Light Toolkit first and understanding what those pieces do, than moving on to Microsoft's Prism, which has some more advanced features.

If you're interested, I also posted something here about using MVVM in a simple application. It shows the actual code for some of the standard MVVM objects such as RelayCommands and INotifyPropertyChanged objects.

  • The speed of learning depends on what you want to learn. Learning the framework gets you up and running faster. Doing it from scratch gets you to understanding why things are done the way they are faster. (But then you need to learn the framework anyways for real life.) – btilly Jun 1 '11 at 17:58

When I learn something new, I write from scratch, or more precisely in the simplest context possible to learn the concept without "noise" until I understand it. Once I understand it well, I'm able to say if it can be done using a framework or other tools, or to write my own tools that provide the concept.

The first pass is often called "prototyping".


Learn it from scratch. Frameworks are there to SPEED UP development by removing the overhead of re-creating common tasks ranging from views to database interactions, whatever things are common to the platform you are going to learn. Additional benefits are things like maintainability, extendability and so on.

After learning the platform, then you can move to a framework, for the above reasons.

You wont have learned a language by learning a framework on it. You will have learned the framework. And some frameworks really abstractify the language they are built to great extent.

AND, most importantly: If you end up working with that language for a long time with a sizable or important application, there WILL come a time at which a framework will be limiting you for a VERY quirky thing the company/firm/workplace/client needs. You will end up having to do wizardry to make it happen. Even the thing you do may appear totally idiotic and irrational to an outsider.

The requirements of the trenches what happen in them can be quite different from what is taught in education institutions.

Not the answer you're looking for? Browse other questions tagged or ask your own question.