BusinessRules ...Versione Italiana

From Dabo Wiki
Jump to: navigation, search

Questo è il cuore di ogni applicazione. Noi la chiamiamo "BusinessRules" [regole dell'applicativo,o più liberamente regole del gioco]? ma anche se la vostra applicazione non è utilizzata per gestire degli affari (per esempio, un'applicazione per gestire la vostra collezione di DVD), sono ancora necessarie queste regole per definire ciò che è accettabile e ciò che non lo è.

Un esempio banale potrebbe essere: hai bisogno di tutti i numeri telefonici per avere anche un prefisso associato.

Una banca dati potrebbe non avere alcun problema a memorizzare una zona di codice bianco, la tua azienda potrebbe, se avesse bisogno di contattare un cliente con quel numero di telefono. Ecco perché questa è una regola aziendale e non un problema di database.

Queste regole sono usate anche per rappresentare processi d'affari.

Per esempio, forse uno you offrire al cliente uno after voce libera che hanno acquistato un certo numero di elementi certain; oggetto your business per gli acquisti recording dovrebbe contenere le code per aggiornare lo stato libero voce del cliente's quando hanno incontrato their targets purchase.

Una buona regola-of-thumb per la progettazione è che si definisce un separato bizobj (comune termine abbreviato di "oggetto di business") per ogni tabella nel database. Dal momento che idealmente una tabella di database rappresenta una singola entità , non ci dovrebbe essere una classe bizobj unico per la gestione di convalida di tale tipo di entità . Ci sono molte eccezioni a questa regola, naturalmente, ma queste sono di solito le questioni di scelte di design di database. Se bastone con la nozione di una bizobj per entità , il vostro codice sarà molto più pulita.