Consigliato in molti libri di architettura software è che non si deve mettere alcuna logica di business nel proprio codice di controller (API). Supponendo che la si implementa nel modo giusto, ad esempio che il codice del controller accede attualmente alla logica di business attraverso una classe di servizio o facciata, il mio suggerimento è che si riutilizzi la stessa classe/facciata di servizio per quello scopo, invece di passare attraverso la porta principale. '(così facendo la chiamata JSON dal codice dietro)
per esempio di base e naieve:
public class MyController1: ApiController {
public string CreateFile() {
var appService = new AppService();
var result = appService.CreateFile();
return result;
}
}
public class MyController2: ApiController {
public string CreateFile() {
var appService = new AppService();
var result = appService.CreateFile();
return result;
}
}
classe AppService incapsula la logica di business (e fa vivere su un altro livello) e rende più facile per voi accedi alla tua logica:
public class AppService: IAppService {
public string MyBusinessLogic1Method() {
....
return result;
}
public string CreateFile() {
using (var writer = new StreamWriter..blah die blah {
.....
return 'whatever result';
}
}
...
}
fonte
2012-04-24 23:16:31
Che cosa si intende per "code-behind"? – SLaks
@SLaks Dire che ho un asp: pulsante. Al suo evento click (lato server/code-behind), vorrei fare un paio di cose e poi chiamare la mia azione API Web (createfile). Spero di essere chiaro. – Rivka
Pls controlla il mio esempio di codice. Forse un po 'ingenuo e semplice, ma è solo per te 2 avere l'idea. –