>>Walter,
>>
>>>We've done some HTML5, C#, MVC, SQL server projects for a patient portal app and clients love it. There is a school nearby which trains young kids to program C# through the MVC model so that is a no-brainer to us.
>>
>>pure noziness: why MVC and not MVVM or one of the other onion-based approaches ? IMO MVC is a pattern from a time when patterns were young, and later born patterns have better/cleaner architecture.
>
>We are investigating all flavours of MVC
>(I do regard MVVM as a flavour of MVC) but my knowledge of the pro and cons from an architectural pov are limited at this point in time.
>
ok, you still need a [minimal] controller, but how/where most biz functionality is settled and implemented has different takes in MVC, MVVM and M-V-P (gets elongated not into Model-View-Pres if spelled without dash...).

My preference for MVVM probably is a bit biased as .value databinding is in vfp genes and vfp is exceptionally well equipped to shoulder the negative aspect of MVVM - [client/ORM] side memory needs, which vfp can always spill to disk in a cursor. Still think it is better if implemented on objects in memory via observer or setter paradigma.

But try think about the way data flows/is accessed and changed early on, as this will influence many of later choices.
Same principles/pattern differences active behind current Javascript way finding between benefits of MobX vs. Redux in React and so on.

my 0.22€ and 0.22$ (I try to find pros & cons on all approaches)...

thomas