2 ms·
Yes, exactly. In ASP.NET MVC land, our our general convention is to have a service layer that does all of the business logic, and the actual MVC web layer only
by mason240 10y ago
Yes, exactly. In ASP.NET MVC land, our our general convention is to have a service layer that does all of the business logic, and the actual MVC web layer only handles UI concerns.
In theory, you set your service layer (just a class assembly) up so that it can handle requests from multiple UI layers (a web MVC layer, a phone app, or even one case, a command line prompt).
MVVM-C seems overly complicated.
- bsaul 10y agoYes indeed. Backend developpers have known "services" layer for a long time, but it seems to be completely unknown to frontend developpers (except maybe angular ones, which heavily promotes this pattern). Model is basically a collection of types, and services are where the business happen and shit gets done. And only in the end should you care about presenting all that stuff in a good looking way. But even this is a bit of a simplification once you get into low-level architectural decisions : is your app real time, does it handle data synchronization with a backend, can it work online and offline , does it need to make certain operations atomically ? Do you have n publisher - n subscribers types of communication between your components ? etc etc. Those are the true questions you need to ask yourself first, and not think in terms of three or four big boxes where you have to put all your junk trying to find descent names.