I min terminologi er en frontendudvilkers opgave at formidle systemets funktioner og muligheder på den mest hensigtsmæssige og effektive måde. Dvs. noget med opsætning og styring af brugergrænsefladen, altså grænsefladen mellem brugeren og systemet. Typisk er det vel så, når man taler en webplatform, noget med at kunne HTML og CSS, samt evt. JavaScript. Alt det der ligger under det niveau (bag ved) er for mig backend, selvom det nok er lidt firkantet anskuet. Der er nok et vis overlap, som frontendudvikleren også kan tage sig af, men jeg ser det ikke som dennes primære opgave. Views ligger i frontendudviklerens domæne, men ikke ViewModels, Controllers og Models.

Backendudvikleren sørger for at modtage, behandle (håndhæve regler) og finde data og servicere bla. frontend med disse. Der kan naturligvis være flere grænseflader ifht. backend, så frontend er blot én abonnent. Models og f.s.v. også controllers ligger, for mig at se, i backendudviklerens domæne. Herunder evt. Viewmodels, der umiddelbart blot er det format (og afgrænsning) data har ifht. frontend.

AJAX er umiddelbart en måde at kommunikere på, så jeg ser det ikke decideret som en specifik frontend eller backend-disciplin.

JavaScript er vel heller ikke udelukkende frontend. Der kan sagtens laves forretningslogik som ligger på klienten og kører i JS. Der findes mange frameworks og biblioteker, der gør understøttelsen af MVC lettere på klienten (AngularJS, Knockout JS, Backbone, Meteor m.fl.)

ASP.NET er et framework som håndterer webapplikationer og deres request-cycles, herunder stiller en masse funktionalitet til rådighed for at facilitere denne process. Jeg synes ikke man udelukkende kan kategorisere ASP.NET som en frontend-teknologi.

Jeg påstår langt fra, at jeg har den endegyldige sandhed om emnet, så ovenstående er bare mine umiddelbare tanker om rollefordelingen.

Med en klasisk opdeling:

system = client tier + app tier + database tier

app tier = presentation layer + business logic layer + data access layer

vil jeg kalde:

client tier + app tier presentation layer = frontend

app tier business logic layer + app tier data access layer + database tier = backend

MVC og MVP boer vaere ren presentation layer og dermed frontend. Det kraever naturligvis at M er en proxy for business logic layer.

@arne: Vil det så sige at M i MVC, iflg. dig, er lig med ViewModel? Jeg opfatter umiddelbart M'et for forretningslaget...

M i MVC er model.

Man kan lave M lig med forretningslaget.

Men i ægte MVC (hvilket MVC web typisk ikke er !) skal M faktisk opdatere V.

Det er ikke business logic at opdatere V.

Derfor ser jeg M som værende en presentation layer del som 1) laver simple passthrough kald til business logic og 2) opdaterer view når C laver opdateringer.

Derudover synes jeg rent praktisk at det giver bedre samling at have en enkelt del af presentation layer M som taler med business logic fremfor to (baade V og C).

Hvis man i stedetfor den traditionelle 3 layer:
  presentation
  business logic
  data access
bruger en 4 layer:
  presentation
  control
  business logic
  data access
saa er:
  V = presentation
  C og M = control

Den opdeling synes jeg ofte giver god mening, da V ofte kraever helt andre skill sets end C og M.

@arne: jeg synes bare jeg har opfattet at det du så definerer M ved, af andre i .NET-miljøet kaldes for ViewModel (bla. Scott Hanselmann). Jeg er helt enig i at det ikke er BL's ansvar at opdatere presentationslaget og din inddeling giver i øvrigt fin mening i men verden.

Der er nok korrekt.

MVVM V = MVC V
MVVM C = MVC C
MVVM VM = MVC M proxy to business logic
MVVM M = business logic

saa hvis vi taler MVVM og ikke MVC, saa er det anderledes.