A che punto l'accesso ai dati \ la logica di manipolazione diventa logica aziendale?

Question

A che punto l'accesso ai dati \ la logica di manipolazione diventa logica aziendale?

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

2

Considera un servizio che aggiorna le tabelle di PersonDetail nel database. Sto usando EF che mappa la tabella con questa Entity. Quando un record viene aggiornato, non viene effettivamente aggiornato ma viene creato un nuovo record e viene creato uno vecchio, impostando HistoryCode su 0

Class PersonDetail
{
  int age;
  Date birthDate;
  DateTime effectiveDate;
  int sequenceNumber; //An incremental number.
  int HistoryCode; //0 represents history record and 1 current record
}

Ora abbiamo un servizio che aggiorna i dettagli della persona

if(newPersonDetail.effectiveDate < currentPersonDetails.effectiveDate)
{
  //update sequence number of currentPersonDetails by 1
  //insert a new Person Details record and assign its sequenceNumber as the sequence number    
  //of currentPersonDetails and HistoryCode as 0 to represent this is an history record
}
else
{
   //Make the currentPersonDetails HistoryCode to 0 from 1
   //Insert a newPersonDetail with sequence number incremented by 1 and HistoryCode set to 0
}

Logic? Sto cercando di spostare la logica di accesso ai dati dal livello di servizio al livello del repository, ma non sono in grado di capire chiaramente quale parte di essa è considerata come logica aziendale e cosa è considerata logica di accesso ai dati.

design business-logic entity-framework

posta Sri Harsha Velicheti 24.03.2014 - 23:04

fonte

4 risposte

Leggi altre domande sui tag design business-logic entity-framework

Il miglior approccio per una raccolta dati di configurazione del server e una soluzione di reporting da uno script legacy? Test Raddoppia, Mock e Stub - quando non usare e perché, per Ruby, Rspec

score 2 · Answer 1

La classe PersonDetail fa parte dell'accesso ai dati. Il servizio che aggiorna PersonDetail è la logica aziendale. Nota che, se non hai realmente bisogno di questa separazione (cioè non avrai bisogno di trapiantare il livello di servizio in qualche altro programma, indipendentemente dall'accesso ai dati), potrebbe non essere importante (sei comunque associato al livello dati , a causa della presenza dei POCO).

score 0 · Answer 2

Sebbene non sia una risposta molto soddisfacente, non appena introduci una condizione (se, passa, ecc.) nel codice del tuo livello dati, stai tecnicamente mescolando logica aziendale e accesso ai dati.

Il motivo per cui non è molto soddisfacente è che questo implica che il codice di accesso ai dati è piuttosto stupido - gestisce la C.R.U.D. solo comportamenti. Ecco perché l'ORM è emerso - ci è voluto quel cervello morto C.R.U.D. roba dai nostri piatti.

Quindi, ora, devi chiarire cosa intendi per livello "accesso ai dati". Molte volte i sistemi saranno un po 'sofisticati e avranno qualcosa chiamato "un livello di accesso ai dati" che è in realtà una combinazione di accesso ai dati e logica aziendale molto fondamentale. Ad esempio, farebbe in modo che non si possa impegnare una "macchina" in un database senza "ruote". Tecnicamente questa è la logica di business, ma è così di basso livello, che va di pari passo con il codice del livello di accesso ai dati (spesso implementato su ORM).

score 0 · Answer 3

Quando si ha a che fare con il codice del livello di accesso ai dati, è possibile pensare a quanto segue:

Pensa a un persistente, qualcosa che fa operazioni sui dati nel livello di persistenza sottostante, come salvare, eliminare e aggiornare le operazioni.
I POJO che rappresentano i record nelle tabelle fanno parte del DAL.
Ogni cosa che dipende e richiede direttamente il layer per utilizzare gli oggetti persistenti nelle operazioni può essere classificata come BL.
Questa dovrebbe essere una relazione unidirezionale, lo strato BLL dovrebbe dipendere da DAL e non il contrario.

Ora il secondo snippet di codice che hai fornito

if(newPersonDetail.effectiveDate < currentPersonDetails.effectiveDate)
{
  //update sequence number of currentPersonDetails by 1
  //insert a new Person Details record and assign its sequenceNumber as the sequence number    
  //of currentPersonDetails and HistoryCode as 0 to represent this is an history record
}
else
{
   //Make the currentPersonDetails HistoryCode to 0 from 1
   //Insert a newPersonDetail with sequence number incremented by 1 and HistoryCode set to 0
}

può essere classificato come BL se è vero in alcuni casi, ma può essere trasferito al DAL nel caso questo sia vero ogni volta che si aggiorna un record.

In alcuni altri casi, BL gestisce direttamente il livello di persistenza per motivi di prestazioni, ma ciò dipende da cosa fa l'applicazione.

score 0 · Answer 4

La tua domanda non può essere risolta in generale, ma il tuo esempio mostra una cosa: differenza tra business logic o requisito e implementazione di quella logica aziendale.

Nel tuo esempio, ma i requisiti aziendali potrebbero essere "Conserva sempre la cronologia delle modifiche a tutti i dettagli personali". Solo perché è implementato come flag all'interno della tabella e non in una tabella separata o in qualche altro modo è il dettaglio dell'implementazione. Il tuo analista aziendale non ha bisogno di sapere come viene implementato questo monitoraggio cronologico. Quindi il codice nel tuo caso può essere descritto come "logica di manipolazione, che implementa un requisito aziendale".