Durante lo sviluppo con MVC ho scoperto questa architettura (basata su Symfony Framework ma ho bisogno di applicarla più in generale sul software di base MVC Pattern):
Inaltreparole,ognimodelloèunafacciatadellamialogicaaziendale.Disolitoèinquestaforma:
<?php//NamespacedefinitionclassSomeModel{publicfunction__construct(Service1$s,Service2$s2){//Settingservicesintoprivateinstancevariables}publicfunctionsomeMethod(){$status=newStatusObj();//Implementationreturn$status;}publicfunctionanotherMethod(){$status=newStatusObj();//Implementationreturn$status;}}
L'implementazioneStatusObjcheusodisolitoèquesta:
Il motivo per cui lo faccio è perché voglio un modo unificato per gestire gli errori e un modo semplice per fabbricare le risposte Http a seconda del caso. Di solito uso pattern di fabbrica per generare la risposta. ad es .: nell'esempio utilizzo
<?php
//Namespace definitions
class HttpResponseFactory
{
public static function generateRestHttpResponse(StatusObj $s)
{
//We suppose that this class models my http reposne
$response=new HttpResponse();
if($s->isErr()) {//In Case an error occured
$err_type=$s->getErrType();//Getting the error Type
switch($err_type){
case StatusObj::Type1:
$response->setHttpStatus(500);
break;
case StatusObj::Type2:
$response->setHttpStatus(500);
break;
}
} else {
$response->setHttpStatus(200);
}
return $response
}
}
Quindi supponiamo di avere questo controller
<?php
//Namespace definitions
class MyController extends SomeGenericControllerClass
{
public function someMethod()
{
//We suppose that somehow we get the Modes via Depedency Injection Container
$model= $this->getServiceFromDepenednyInjection('SomeModel');
$status= $model->someMethod();
return HttpResponseFactory::generateRestHttpResponse($status);
}
public function anotherMethod()
{
//We suppose that somehow we get the Modes via Depedency Injection Container
$model= $this->getServiceFromDepenednyInjection('SomeModel');
$status= $model->anotherMethod();
return HttpResponseFactory::generateRestHttpResponse($status);
}
}
In questo modo cerco di avere il DRY come possibile per la gestione della risposta http (e non solo). Nel caso in cui l'eccezione è stata generata viene gestita sul modello e viene generato lo stato corretto. Inoltre, a seconda del tipo di risposta http potrebbe avere più di una fabbrica, lo stesso vale nel caso in cui desideriamo eseguire alcuni comandi a seconda del framework.
Ma voglio sapere quali avvertenze - possono essere contrarie a questa architettura sopra menzionata in termini di:
- Riutilizzabilità e leggibilità del codice.
- Manutenzione del software.
- Future Improvement conclude l'estensione con nuove funzionalità.
Lo consiglieresti questo al tuo capo?