Domanda

Ho cercato questo per molto tempo (anche qui), ho letto molti codici php, ma ancora non sono riuscito a trovare una risposta soddisfacente. Può sembrare un argomento troppo ampio, ma si attacca davvero, finalmente per me. Potresti aiutarmi, per favore?

In un sito Web php ho PDO come DAL, ciò che viene utilizzato dagli oggetti BLL e vengono chiamati dall'interfaccia utente. Ora se accade qualcosa , DOP genera un'eccezione PDO. Ovviamente il layer UI non deve sapere nulla delle PDOExceptions, quindi l'oggetto BLL lo cattura. Ma ora cosa?

L'ho letto

  1. le eccezioni sono per situazioni veramente eccezionali e
  2. si rigenera le eccezioni dai livelli inferiori per non ottenere eccezioni di basso livello nei livelli superiori.

Lasciami illustrare il mio problema (per favore non prestare attenzione alla funzione args):

class User
{
 function signUp()
 {
  try
  {
   //executes a PDO query
   //returns a code/flag/string hinting the status of the sign up:
   //success, username taken, etc.
  }
  catch (PDOException $e)
  {
   //take the appropriate measure, e.g. a rollback

   //DataAccessException gets all the information (e.g. message, stack
   //trace) of PDOException, and maybe adds some other information too
   //if not, it is like a "conversion" from PDOException to DAE
   throw new DataAccessException();
  }
 }
}

//and in an upper layer
$user = new User();
try
{
 $status = $user->signUp();
 //display a message regarding the outcome of the operation
 //if it was technically successful
}
catch (DataAccessException $e)
{
 //a technical problem occurred
 //log it, and display a friendly error message
 //no other exception is thrown
}

È una soluzione giusta? Quando si rilancia PDOException, non penso che sarebbe opportuno utilizzare il concatenamento delle eccezioni (poiché ciò renderebbe ridondanti solo le informazioni di debug; DataAccessException ottiene tutto, inclusa la traccia dello stack completo da PDOException).

Grazie in anticipo.

È stato utile?

Soluzione

Come ho capito il tuo post, una buona risorsa è questa: Api design

Penso che tu abbia fatto i compiti (se posso usare la frase) ma hai dimenticato il motivo per cui questa cosa è stata fatta. Nel tuo esempio creerei qualcosa di simile

SignUpException

che informerebbe gli strati superiori che qualcosa è andato storto nell'iscrizione. Quello che fai qui è essenzialmente mascherare un'eccezione del database con un nome diverso, che è essenzialmente la stessa cosa, qualcosa che, sebbene programmaticamente corretto, manca il punto del perché di farlo nel primo posto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top