MVVM Series: Introduction
My head hurts just thinking about MVVM...
There's quite a lot of rhetoric out there about what MVVM is and how to best implement it. And the hard part is that a lot of it is correct, even though seemingly at odds at times. To add to the confusion, I put forth my own opinion that, as with all true engineering efforts, you need to use your brain and do what works best for you, your team, and your products.
This the heart of MVVM to me - MVVM is simply a pattern that can be used to make your software of a higher quality and more reusable and resilient to layer/requirement changes. Use it as best suits your needs. Forget about what you may hear or read about the 'rules' or 'laws' or MVVM - there are none. It's a pattern. Nothing more. Some people say that you should have no code-behind, ever. Some say you can. The correct information is that there are no rules about code-behind or anything else, because it is...just...a...pattern, not a programming language, IDE, etc.
MVVM is not for everyone. It's a complicated pattern to implement and requires a focused and disciplined approach to implement in the absolute best manner possible. However, there is quite a lot of middle ground as your familiarity with MVVM and your understanding of what the pattern is trying to accomplish both grow, coupled with all its gotchas and (at times) simplicities.
So, you can start out worrying about just the basics like bindings between your View and ViewModel, then move on to other pieces of it as you have time and are comfortable. I'm still finding ways to improve my implementation after doing it for nearly 2 years.
Also, especially when beginning MVVM, you will find that your estimates for development will need to be lengthened a bit. It does take longer to implement until you get the hang of it. This can take anywhere from a month or two to a year or more (it's up to you).
But the reward is that once you are savvy, your development times will speed up and your software will enhancements/features will go all that much faster because of the many benefits the patterns provides for software management. I'm finding that I'm able to enhance features or create new ones in my products much, much faster because of MVVM than without. But you must pay the penalty up front for learning it, and your manager must be convinced that it is worth it.
If you do decide to take the plunge into MVVM, my hats off to you. You will be amply rewarded for years to come as the pattern, although specific to XAML based technologies, is replicated in other technologies under different names - all of which are not going away, and all of which are becoming the de facto standard for software development whether you are developing at the enterprise, desktop, mobile, or web platforms. In your Googling, you will see other acronyms like MVC and MVP. If you are familiar with those, then you will much more easily become familiar with MVVM.
As a caveat, if you are interested in learning MVVM but do not yet know WPF or Silverlight, I would strongly advise learning WPF or Silverlight first. Come back here when you've learned some XAML. Combining MVVM learning with XAML basics is like trying to learn how to do a barrel roll when you haven't learned how to take off yet. You can get lucky and learn both at the same time, but you're likely to incur a lot of damage along the way.
Definition
So, what is it? Model-View-ViewModel. Simply put, the ViewModel acts as the business logic for shuffling data to and from the View (UI/XAML) and the Model (back-end entities or the data layer).
Overview
In my series, I'll present each aspect of MVVM as a concept as I have come to understand it, then present a portion of a real world, MVVM application that applies the concept. Throughout the series, I'll create the pieces and (hopefully) adequately explain the 'gotchas' we all have or will encounter along the way. I'll also be explaining other software constructs that often accompany any MVVM implementation, what they are for, and give an example implementation for each.
My entire series will not use any 3rd party MVVM or SoC (e.g. Prism) framework of any kind. The code is meant to be investigated and understood; to take away the 'magic' that some MVVM frameworks may give you to promote a low level understanding of how this all really fits together. Each component I discuss and create will be tailored to my application, but generalized where it makes sense. I'll post the code along the way...
So (as a placeholder for now), here the topics to follow (in the order that makes the most sense to me to present):
The View
What is it, what is it not
An example View
Common View Construct - Controller or View injector
The ViewModel
What defines an ideal ViewModel (i.e. Unit testability!!)
Custom ViewModelBase class
Example ViewModel
Common ViewModel constructs - ViewModel injector, IUiDispatcher Service, IMessageBoxService, IMessagingService
The Model
Typical usage
IDataErrorInfo implementation (generic) - simple ModelBase class
Example Model
Model usage to abstract the actual data layer (plug and play back ends)
Common Model construct - Data Service
Until next time...
There's quite a lot of rhetoric out there about what MVVM is and how to best implement it. And the hard part is that a lot of it is correct, even though seemingly at odds at times. To add to the confusion, I put forth my own opinion that, as with all true engineering efforts, you need to use your brain and do what works best for you, your team, and your products.
This the heart of MVVM to me - MVVM is simply a pattern that can be used to make your software of a higher quality and more reusable and resilient to layer/requirement changes. Use it as best suits your needs. Forget about what you may hear or read about the 'rules' or 'laws' or MVVM - there are none. It's a pattern. Nothing more. Some people say that you should have no code-behind, ever. Some say you can. The correct information is that there are no rules about code-behind or anything else, because it is...just...a...pattern, not a programming language, IDE, etc.
MVVM is not for everyone. It's a complicated pattern to implement and requires a focused and disciplined approach to implement in the absolute best manner possible. However, there is quite a lot of middle ground as your familiarity with MVVM and your understanding of what the pattern is trying to accomplish both grow, coupled with all its gotchas and (at times) simplicities.
So, you can start out worrying about just the basics like bindings between your View and ViewModel, then move on to other pieces of it as you have time and are comfortable. I'm still finding ways to improve my implementation after doing it for nearly 2 years.
Also, especially when beginning MVVM, you will find that your estimates for development will need to be lengthened a bit. It does take longer to implement until you get the hang of it. This can take anywhere from a month or two to a year or more (it's up to you).
But the reward is that once you are savvy, your development times will speed up and your software will enhancements/features will go all that much faster because of the many benefits the patterns provides for software management. I'm finding that I'm able to enhance features or create new ones in my products much, much faster because of MVVM than without. But you must pay the penalty up front for learning it, and your manager must be convinced that it is worth it.
If you do decide to take the plunge into MVVM, my hats off to you. You will be amply rewarded for years to come as the pattern, although specific to XAML based technologies, is replicated in other technologies under different names - all of which are not going away, and all of which are becoming the de facto standard for software development whether you are developing at the enterprise, desktop, mobile, or web platforms. In your Googling, you will see other acronyms like MVC and MVP. If you are familiar with those, then you will much more easily become familiar with MVVM.
As a caveat, if you are interested in learning MVVM but do not yet know WPF or Silverlight, I would strongly advise learning WPF or Silverlight first. Come back here when you've learned some XAML. Combining MVVM learning with XAML basics is like trying to learn how to do a barrel roll when you haven't learned how to take off yet. You can get lucky and learn both at the same time, but you're likely to incur a lot of damage along the way.
Definition
So, what is it? Model-View-ViewModel. Simply put, the ViewModel acts as the business logic for shuffling data to and from the View (UI/XAML) and the Model (back-end entities or the data layer).
Overview
In my series, I'll present each aspect of MVVM as a concept as I have come to understand it, then present a portion of a real world, MVVM application that applies the concept. Throughout the series, I'll create the pieces and (hopefully) adequately explain the 'gotchas' we all have or will encounter along the way. I'll also be explaining other software constructs that often accompany any MVVM implementation, what they are for, and give an example implementation for each.
My entire series will not use any 3rd party MVVM or SoC (e.g. Prism) framework of any kind. The code is meant to be investigated and understood; to take away the 'magic' that some MVVM frameworks may give you to promote a low level understanding of how this all really fits together. Each component I discuss and create will be tailored to my application, but generalized where it makes sense. I'll post the code along the way...
So (as a placeholder for now), here the topics to follow (in the order that makes the most sense to me to present):
The View
What is it, what is it not
An example View
Common View Construct - Controller or View injector
The ViewModel
What defines an ideal ViewModel (i.e. Unit testability!!)
Custom ViewModelBase class
Example ViewModel
Common ViewModel constructs - ViewModel injector, IUiDispatcher Service, IMessageBoxService, IMessagingService
The Model
Typical usage
IDataErrorInfo implementation (generic) - simple ModelBase class
Example Model
Model usage to abstract the actual data layer (plug and play back ends)
Common Model construct - Data Service
Until next time...
Comments
Post a Comment