I'd argue that regular applications are often a sea of interconnecting MVC applications.
eg a dialog box represents a little MVC island, involving the data that's being collected - and only when they choose OK (or hopefully a verb better representing the task), does the dialog's data get incorporated into the wider application's Model.
My own preference with web applications is to do as you consider - implement the server side as effectively web services (though not necessarily SOAP or XML based, my preference is JSON for complex data), and do as much of the application as makes sense client-side. Typically the only places that I'll do page transitions are when it makes sense from a backtrack/bookmark perspective.
If anything this makes security easier, because you at least have a well defined business logic layer, rather than having all those decisions intertwined with your user interface.
by Andrew Barry — Aug 02
eg a dialog box represents a little MVC island, involving the data that's being collected - and only when they choose OK (or hopefully a verb better representing the task), does the dialog's data get incorporated into the wider application's Model.
My own preference with web applications is to do as you consider - implement the server side as effectively web services (though not necessarily SOAP or XML based, my preference is JSON for complex data), and do as much of the application as makes sense client-side. Typically the only places that I'll do page transitions are when it makes sense from a backtrack/bookmark perspective.
If anything this makes security easier, because you at least have a well defined business logic layer, rather than having all those decisions intertwined with your user interface.