Just talking about internal applications or intranet web apps... At some companies I've seen their business-logic piece (Model in MVC/VM in MVVM) on one (or both) sides of a Web Service.  And on the other side of the web service is the Persistence.MVC/MVVM > Service Layer > PersistenceThis is only for intranet/internal application customers, and both the web or app code, and the persistence (usually ORM) dlls both sit on the same server, or even in the same folder.I'm used to seeing internal apps and intranet websites that reference a business-layer... then that business-layer connects to persistence.  So the app itself is persistence-ignorant.But with my own apps, if something needed to be exposed externally, that something is opened up via a web service.  But otherwise, everything stays internal.Is there a reason for why I've seen a couple different companies do this?  They didn't seem to know the answer themselves.
Should my internal MVC/MVVM application use Web Services for Persistence?
mvc;web services;mvvm;persistence
I tend to think that's a bit silly. More formally, it's an example of what I would call speculative generality. The counterargument would be that the architecture you describe allows for other sorts of clients to be easily plugged into the same system with less effort, and that one never really knows what sort of new direction the project might take. (Realistically, though, sometimes these things can be known to a very great extent. Pretending everything's an unknown and requires generalization can be a very bad way to work, in my experience.)I suppose that the deciding factor is how much effort the team thinks it will take to use Web Services. Superficially, it doesn't seem like the sort of thing that would require too much extra work. However, debugging and configuration implications must be considered (as opposed to just the code itself), and that's where I think that the Web Services approach probably damages the developer experience.