Sono un programmatore abbastanza giovane, ma felice di imparare! :) Ho creato un'applicazione basata su WebApi e l'ho inviata per essere esaminata dal mio collega. L'ho recuperato con l'opinione che il modo in cui utilizzo le classi parziali nascondono la complessità e le dimensioni del controller. Sono davvero felice di sentire la sua opinione (è stato uno sviluppatore per più di 15 anni) perché lo rispetto. Ma mi piace sottoporre a controllo le opinioni, i punti di vista per vedere il maggior numero possibile di aspetti di un caso.
Puoi trovare esempi e schermate qui sotto sul codice.
I motivi per cui organizzo le mie cose sono i seguenti:
- facile trovare il metodo del controller in solution explorer
- un file (una classe parziale) contiene solo un singolo metodo e i suoi metodi di utilità interni (se ce n'è uno). Se un metodo di utilità viene utilizzato da più metodi di controller, li organizzo in un luogo comune
- un controller è responsabile di un singolo endpoint (nell'esempio è possibile vedere il controller dell'ambiente responsabile del sottodominio dell'ambiente)
- un metodo non è mai più lungo di una dimensione dello schermo comune per due motivi: a, odio scorrere verso l'alto e verso il basso, b, la logica di business del controller viene estratta in una libreria separata chiamata Application, il controller responsabile solo per chiamare il metodo dell'applicazione e restituire il risultato.
Il mio collega ha detto che, le classi parziali sono fantastiche quando una classe implementa più interfacce e puoi separare le implementazioni dell'interfaccia in classi parziali.
Le mie domande :
- sono sufficienti informazioni e esempi di codice che ho fornito?
- è un buon approccio che ho?
- se non allora dove sono i punti deboli e perché?
- qual è lo schema comune in queste aree, tuttavia, la revisione del codice è piuttosto un insieme comune di opinioni e cultura di un team / azienda
- dove si trova il salutare trade-off tra leggibilità / gestibilità (in base al risultato della revisione del codice ho spinto un po 'questa parte) e nascondendo la complessità, violando le regole di responsabilità
File EnvironmentController.cs: è responsabile (contiene solo) per l'impostazione relativa alla dipendenza da dipendenza (iniezione costruttore), elenca i campi e ha il valore RoutePath.
[RoutePrefix("Environment/Environments")]
public partial class EnvironmentController : ApiController
{
private IEnvironmentApplication environmentApplication;
public EnvironmentController(IEnvironmentApplication environmentApplication)
{
this.environmentApplication = environmentApplication;
}
}
EnvironmentController.AddNewEnvironment.cs: responsabile solo del metodo AddNewEnvironment e dei possibili metodi di utilità interni, se disponibile
public partial class EnvironmentController
{
[HttpPost]
[Route("AddNewEnvironment")]
public HttpResponseMessage AddNewEnvironment([FromBody] string environmentViewModelString)
{
try
{
EnvironmentViewModel model = JsonConvert.DeserializeObject<EnvironmentViewModel>(
environmentViewModelString,
new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore });
EnvironmentContract result = this.environmentApplication.AddNewEnvironment(model);
return this.Request.CreateResponse(HttpStatusCode.Accepted, result);
}
catch (Exception e)
{
return this.Request.CreateErrorResponse(HttpStatusCode.BadRequest, e);
}
}
}
Come appare in solution explorer.
