|
I had the Apple thing all figured out after I got the first IPad (that they supported for about 2 years) and having to deal with ITunes...
The other half bought an IPad Mini recently that became "unusable" after about a month (and which I do not want to touch).
|
|
|
|
|
What happened? I my iPad mini (except it's first gen and slow on the latest OSs)
cheers
Chris Maunder
|
|
|
|
|
I should state that I am a crusty old Visual C++/C# developer firmly in the event-driven paradigm camp (NOTE: I detested on principle the clunky macro architecture for the Visual C++ message map, but admit that it do the job), although I appreciate the way that OpenOffice Calc (or Micro$oft Excel) works, which I understand is basically by using the functional programming paradigm. I never got much into XAML as I went into early retirement about the time that got to be the new k3wl thing.
I was reading this article (sent to me by CodeProject) about MVVM:
4 Reasons To Drop MVVM[^]
Reading this article, it seems to me that MVVM is simply the functional programming paradigm used for the GUI. Is this accurate? I understand how the functional programming paradigm makes Calc work so well, but also that it only works well when the processing is simple, otherwise a whole lot of funky cells containing state has to be used. My personal opinion is that a GUI is inherently something that needs to be event-driven, and that trying to shoehorn it into the functional programming paradigm just results in boilerplate processing that an be very inefficient.
I distinctly remember using Excel on a clunky Windows 3.1 386 machine (yes, LOL) and having the status bar give the message "Calculating" along with some percentage for *any* change in cell - and as well remember a project in which I was to make something that was like a GridCell, but out of TextBox controls, and I had to do a lot of careful enabled state design so that it made sense; I can't fathom doing that using the functional programming paradigm.
|
|
|
|
|
From the article: "since I primarily do web applications..."
That automatically invalidates anything he says about MVVM. Beyond that, MVVM isn't about "functional" anything - functional programming is the antithesis of object oriented programming. MVVM is more about separation of concerns (UI and data), and is merely a guideline for providing the UI a method of introducing data to the user.
From the artle: "MVVM is slow"
That is most certainly NOT my experience. If it's slow, he should hire a decent DBA to construct his database and write the associated stored procedures. I'm most certainly not what I would call good at database design, but my MVVM apps freakin scream.
The guy that wrote the article is a freakin idiot.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
|
I think he is writing from the perspective of Angular. I don't think he is referring to WPF or WinRT. That said, his article is not logical and does exaggerate a fair bit.
|
|
|
|
|
Personally I find that MVVM done right is so much more maintainable then other options. Of course it is going to impact speed. If that was a major concern we would still be programming strictly in C, not even C++. It is hard not to impact speed when trying to make programmers more powerful. Using HTML impacts speed so should we abandon HTML. My current design is being taken over by another programmer, and it has been very easy for her to follow the code. What I took over was WPF, but must have been done by programmers that are not really WPF programmers. This is not to say that there may not be the possibility of creating anything better. There definitely is, but it would probably be slower. When I have not used the MVVM pattern, I have sworn because it would not have been that much more difficult and would have made it so much easier to enhance the application.
|
|
|
|
|
Clifford Nelson wrote: Personally I find that MVVM done right is so much more maintainable then other options.
I find that most anything done right is more maintainable than other options.
|
|
|
|
|
Spot on.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I think your understanding has been hijacked and muddled by entreprisey people!
Go to this simple and straight to the point MVVM introductory article:
MVVM for beginners[^] (shameless plug! )
(Remark this article focus on MVVM with XAML, as far as I know MVVM with javascript is still possible but more difficult, look at VueJS[^] or KnockoutJS[^])
And then see for your self when and where you want to use it.
"Big debate" around MVVM are misleaded.. It's a nice GUI code simplification tool to use whenever appropriate....
And if it doesn't simplify things then it's not appropriate (for that particular problem), or maybe you are still confused...
|
|
|
|
|
|
swampwiz wrote: MVVM is simply the functional programming paradigm used for the GUI. Is this accurate?
No. MVVM is simply an abstract architectural pattern. A bit of history:
MVC - Model / View / Controller, was a useful concept in the sense that it separated the concerns of:
- model: managing the persistence of the data
- view: managing the display of the data and wiring up the UI events
- controller: the "business logic", if you will, of what to do to the model in response to UI events.
Hidden in MVC is that model events are wired up by the view, so it updates the UI when the model changes.
The theory of MVC is that each could change more-or-less independently of the other to extend the behavior of the initial design.
MVC doesn't work to well because the model is usually more closely tied to the actual database tables handling the persistence.
MVVM (Model, View, View-Model) attempts to correct that by recognizing that there is a model (usually the database tables) that doesn't map well to the UI, hence there is an intermediate "view-model" for how the UI wants to actually display the data. Think of DB views, but you can't use those as the model because DB views are usually read-only.
Note the controller is also implicit in the "view-model."
MVVM doesn't work well either, because really, the pieces that you need are:
DB model - Application model interface. The DB can still represent things in ways the application doesn't and shouldn't care about, for reasons of DB optimization, whatever. So while the two can be frequently combined, they shouldn't. One way to create a nice clean separation is to not directly have the application talk to the DB, but use a middle tier (like a REST service) that knows how to translate between DB and application models.
View model - Application model interface. This is like the "VM", in the sense that it recognizes that even the application model doesn't translate well to what the view needs.
View - controller interface. This abstraction should still be explicitly implemented so that neither the view, nor the view-model, nor the application model, do anything beyond their limited tasks. The controller is where the smarts are, updating the application model, making the necessary REST calls to update the back end, managing caching, other services (via other controllers) that come in to play, etc.
But nobody wants an acronym like DBVAVMVCRAPI
Marc
|
|
|
|
|
I feel I have to offer minor clarifications here. In MVVM, there may be many models associated with a single view. I am not talking about mapping multiple database tables here, although that may be the case. The model is simply something that isn't view or view model. It's common for the VM to coordinate validation from a validation model, with calls out to cache data and so on. These would all be models and the VM is the glue that binds them together. This is because it's an architectural pattern. If it wasn't, then doing things like n tier design would be incredibly complicated.
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: I feel I have to offer minor clarifications here.
Thank you -- excellent points.
Marc
|
|
|
|
|
Don't really agree with your characterization of what a "Model" is in MVC/MVVM. It doesn't really have anything to do with the DB. There should be a translation layer between the "Model" and the DB as well as between the "Model" and the view. The MVC pattern can be used for both sides.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: It doesn't really have anything to do with the DB. There should be a translation layer between the "Model" and the DB as well as between the "Model" and the view.
Exactly, which is why I came up with the acronym that would never be used.
Marc
|
|
|
|
|
Understood.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
The 7y/o autistic granddaughter of a close friend drowned just a couple of days ago. During the 10 minutes it took to prepare dinner, she apparently unlocked the door and walked across the street to a neighbor's pool where she had been swimming just a few days before with her mother. Yes, there was a privacy fence around the pool, but the gate wasn't locked.
Please, if you live in a neighborhood with small or autistic children and have a swimming pool, invest in a childproof lock for your pool gate.
I can't imagine what the family must be going through.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Very sad indeed!
In South Africa where we used to live pool safety regulations were strictly enforced. Child proof fences with automatic child proof locks on the gates were mandatory. Something we can really copy here in the USA with all the private pools.
Get me coffee and no one gets hurt!
|
|
|
|
|
That IS the law in many places in the US.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
The problem with childproofing things is that it engenders a false sense of security. The most important thing is to take good care of your children, and always know where they are.
|
|
|
|
|
Richard MacCutchan wrote: and always know where they are. Spoken like someone who never had kids.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Just as I was beginning to gain some respect for you.
|
|
|
|
|
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
You know nothing about me or my life: how many children I've had, how many have serious life threatening diseases, or were killed or injured in accidents. So kindly keep your stupid comments to yourself.
|
|
|
|