Is a separate view model relevant for Blazor server side given that we can test the whole component with bUnit?
-
When writing software, whether desktop or web-based, I have always separated the view from the view model. For example, in WPF (Microsoft desktop technology), I used MVVM, kept the XAML view as light as possible and put the logic and data access into a separate view model (regular C# class). One of the main advantages of this is that it makes the view model easy to unit test, as I can set up mock dependencies, set the public properties that would normally be set by dependency injection or property binding and then call methods no the view model to test the code. Nowadays I do pretty much everything in Blazor server-side, and used the same approach. My .razor file is pure markup, the .razor.cs file usually only contains overloads for the component life-cycle events, and generally passes the request through to the view model (as above). However, one of my co-workers is encouraging the team to put all code into the .razor.cs file, and use bUnit to unit test the components. Given that we can mock dependencies, set public parameters and call methods, it does look as if this gives all the benefits of a separate view model, without needing the extra file. Anyone any thoughts as to the advantages or disadvantages of either approach? Thanks
-
When writing software, whether desktop or web-based, I have always separated the view from the view model. For example, in WPF (Microsoft desktop technology), I used MVVM, kept the XAML view as light as possible and put the logic and data access into a separate view model (regular C# class). One of the main advantages of this is that it makes the view model easy to unit test, as I can set up mock dependencies, set the public properties that would normally be set by dependency injection or property binding and then call methods no the view model to test the code. Nowadays I do pretty much everything in Blazor server-side, and used the same approach. My .razor file is pure markup, the .razor.cs file usually only contains overloads for the component life-cycle events, and generally passes the request through to the view model (as above). However, one of my co-workers is encouraging the team to put all code into the .razor.cs file, and use bUnit to unit test the components. Given that we can mock dependencies, set public parameters and call methods, it does look as if this gives all the benefits of a separate view model, without needing the extra file. Anyone any thoughts as to the advantages or disadvantages of either approach? Thanks
The whole "view model thing" started with the idea "visual designers" would do views; and "programmers" would do "models"; that "connected" to the view "transparently"; through the magic of "binding"; ignoring that the binding has to understand both; so that there is no "real" separation; and one bleeds into the other; without "seeing" it. The average life of an app is 5 years. Few run on "so many" platforms that it needs sparate "views" and separate "models" in order to run. The path of least resistance is not MVVM.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
The whole "view model thing" started with the idea "visual designers" would do views; and "programmers" would do "models"; that "connected" to the view "transparently"; through the magic of "binding"; ignoring that the binding has to understand both; so that there is no "real" separation; and one bleeds into the other; without "seeing" it. The average life of an app is 5 years. Few run on "so many" platforms that it needs sparate "views" and separate "models" in order to run. The path of least resistance is not MVVM.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Thanks for the reply, but I'm not sure I agree with you on quite a few points. View models (in the general sense of any MV* patterns) first came to the public attention in 1979 with Smalltalk, whereas the first visual designers for software development weren't until at least a decade later. Visual Basic was probably the first real visual designer, but didn't came out until 1991. Even if you want to stretch the point and include things like Hypercard, you only get a few more years (1987), still well after view models. My understanding is that the point of view models was to separate the data access, logic and models from the UI. Yes, this was partly to allow the two to be developed independently, and possibly by different teams, but also (and possibly more importantly) to allow the former to be unit tested, something that was impossible in the early days of UI, and is still not so easy. However, I don't really see the relevance. The idea of separating code into separate units is still useful, and binding is merely the common agreement between them. It doesn't really imply any bleeding going on. The view model can expose properties to be bound, and it's up to the view to choose whether or not to bind to them. That's not such a strong dependency. Finally, even assuming your estimate of the average age of an app to be correct (which I would dispute, as I still maintain several projects that have been active for 10, 15 and in one case 25 years), why is that relevant? Length of life is not generally a determining factor in how you structure your projects, and separating layers is not just for multiple platforms. Don't mean to be rude, but I really don't see how any of your points address my question. Please feel free to clarify if I've missed something.
-
Thanks for the reply, but I'm not sure I agree with you on quite a few points. View models (in the general sense of any MV* patterns) first came to the public attention in 1979 with Smalltalk, whereas the first visual designers for software development weren't until at least a decade later. Visual Basic was probably the first real visual designer, but didn't came out until 1991. Even if you want to stretch the point and include things like Hypercard, you only get a few more years (1987), still well after view models. My understanding is that the point of view models was to separate the data access, logic and models from the UI. Yes, this was partly to allow the two to be developed independently, and possibly by different teams, but also (and possibly more importantly) to allow the former to be unit tested, something that was impossible in the early days of UI, and is still not so easy. However, I don't really see the relevance. The idea of separating code into separate units is still useful, and binding is merely the common agreement between them. It doesn't really imply any bleeding going on. The view model can expose properties to be bound, and it's up to the view to choose whether or not to bind to them. That's not such a strong dependency. Finally, even assuming your estimate of the average age of an app to be correct (which I would dispute, as I still maintain several projects that have been active for 10, 15 and in one case 25 years), why is that relevant? Length of life is not generally a determining factor in how you structure your projects, and separating layers is not just for multiple platforms. Don't mean to be rude, but I really don't see how any of your points address my question. Please feel free to clarify if I've missed something.
I've seem enough questions on "how do I ... in MVVM" to know that it is (mostly) just another albatross. Other than familiar "CRUD" LOB applictions, MVVM tends to over-complicate things: to the point that development takes longer and desirable features aren't implemented because "they" cannot figure out how to do it without "code behind" (and therefore "breaking" MVVM "rules"). MVVM is a recipe for mediocre software and budget and time overruns.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I've seem enough questions on "how do I ... in MVVM" to know that it is (mostly) just another albatross. Other than familiar "CRUD" LOB applictions, MVVM tends to over-complicate things: to the point that development takes longer and desirable features aren't implemented because "they" cannot figure out how to do it without "code behind" (and therefore "breaking" MVVM "rules"). MVVM is a recipe for mediocre software and budget and time overruns.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
OK, I guess our experiences are obviously very different. I find MVVM a fantastic way of keeping the concerns separate, and the ease of unit testing has improved both speed of development and ease of fixing bugs significantly. I've never, ever not implemented something because MVVM got in the way. To me, MVVM is a recipe for faster and more stable development. As I said, I guess it depends on your experience. Thanks anyway
-
When writing software, whether desktop or web-based, I have always separated the view from the view model. For example, in WPF (Microsoft desktop technology), I used MVVM, kept the XAML view as light as possible and put the logic and data access into a separate view model (regular C# class). One of the main advantages of this is that it makes the view model easy to unit test, as I can set up mock dependencies, set the public properties that would normally be set by dependency injection or property binding and then call methods no the view model to test the code. Nowadays I do pretty much everything in Blazor server-side, and used the same approach. My .razor file is pure markup, the .razor.cs file usually only contains overloads for the component life-cycle events, and generally passes the request through to the view model (as above). However, one of my co-workers is encouraging the team to put all code into the .razor.cs file, and use bUnit to unit test the components. Given that we can mock dependencies, set public parameters and call methods, it does look as if this gives all the benefits of a separate view model, without needing the extra file. Anyone any thoughts as to the advantages or disadvantages of either approach? Thanks
Mr Yossu wrote:
one of my co-workers is encouraging the team to put all code into the .razor.cs file
So a single file. Unless the application is very small or there is zero functionality in that code then no that is a bad idea. And maybe even for the second it still might not be a good idea. Since presumably the file is modified by humans (not generated) then obviously the line count is a good demarcation. Is it going to be 100,000 lines long? Now? Or in the next 5 years then absolutely not. If it is 20 lines long now and will be at most 100 in 5 years then it doesn't matter.