Logica di business in informatica. La logica di business può essere trovata in qualsiasi applicazione in cui è necessario prendere decisioni su quali dati debbano andare nel database e come debbano comportarsi quando vi si accede. È spesso indipendente dal livello di presentazione in modo da non avere un impatto significativo sulle prestazioni dell’interfaccia utente, ma tutte le regole di business devono comunque seguire le migliori pratiche del settore per scrivere applicazioni altamente ottimizzate con bug minimi.

Regole di business – Questo argomento si riferisce a test di validazione personalizzati applicati prima/dopo l’inserimento, l’aggiornamento o la cancellazione degli id dei documenti dai database. Queste funzioni di “dominio” permettono agli sviluppatori di scrivere codice una sola volta utilizzando standard basati su precedenti esperienze testate.

Logica di business

È possibile implementare complesse regole di business con semplici query SQL.
Si potrebbe pensare che non c’è molta differenza tra l’implementazione di una regola in memoria, o memorizzarla come stored procedure. Ma cosa succede se la logica dietro la vostra decisione deve cambiare?

Per esempio, diciamo che un giorno decidete che aggiungere una clausola else avrà più senso per qualche motivo; ora tutto inizia a cadere a pezzi perché quei due pezzi non sono più collegati!

Con LINQ-to SQL però (e le classi itspartial), questo non accade poiché sono entità separate per progettazione.

Logica di business

Quando si genera una classe entità al momento della progettazione, sia manualmente che usando l’Object Relational Designer (OR DSL), essa è definita come una classe parziale.

Questo significa che in file di codice separati ci può essere un’altra parte della tua regola di business personalizzata per definire tabelle e colonne di database/tipi di dati di base. Questi si fonderanno insieme alle altre classi compilate quando verranno caricate in memoria durante il gioco. In questo modo nessun cambiamento avviene se si rigenera qualsiasi oscurità OT generata!

Proseguendo….

Logica di business

Le classi parziali che definiscono entità e Data Context contengono metodi parziali. Questi sono punti di estensibilità che si possono usare per applicare la regola di business prima di un aggiornamento, inserimento o cancellazione di una proprietà sulla classe entità. Sono un po’ come ascoltatori di eventi in alcuni casi! Il generatore di codice definisce le firme per questi metodi in modo da sapere cosa deve essere fatto al momento della compilazione.

Tutto ciò senza avere alcuna idea di quanto complesse possano essere le prestazioni di questi cambiamenti (dato che questo dipenderà in gran parte da dove all’interno del ciclo di elaborazione della nostra applicazione ogni ascoltatore è definito).

La definizione dell’implementazione scritta in un file di codice separato può eseguire la regola personalizzata necessaria. Avete due opzioni per come volete usare questa classe parziale. Come vostro livello di dominio o chiamando da una delle sue implementazioni all’interno di un altro oggetto che è stato compilato con una modalità di compilazione ad albero di espressione abilitata. Il che ci permetterà di avere a disposizione tutti i tipi di regole di cui abbiamo bisogno!

Logica di business

Questo articolo rivela come personalizzare il comportamento di inserimento, aggiornamento e cancellazione delle classi entità implementando un’intera classe parziale.

Quando si inviano modifiche attraverso questa nuova funzionalità, essa richiamerà qualsiasi codice di sostituzione rilevante per ogni operazione, invece di provenire dai propri metodi predefiniti – creando un SinglesHOLE dove prima non ce n’era nessuno!

Quando la classe Customer viene modificata, ci sono tre metodi chiamati da LINQ to SQL runtime. Uno di questi si verifica quando un nuovo oggetto cliente è stato creato e caricato in memoria; è noto come metodo CreateObject.

Questo permette ai nomi utente o alle password per esempio di essere memorizzati in modo sicuro senza essere leggibili da nessun altro che il loro legittimo proprietario! La seconda volta abbiamo il nostro metodo Validate che segue tutte le regole stabilite in strictBusinessLogic-RegularExpression TEMPLATE.

Implementazione

#region Extensibility Method Definitions partial void OnLoaded(); partial void OnValidate(); partial void OnCreated(); partial void OnCustomerIDChanging(string value); partial void OnCustomerIDChanged(); partial void OnCompanyNameChanging(string value); partial void OnCompanyNameChanged(); // ...additional Changing/Changed methods for each property


La funzione set access viene chiamata quando si cambia il valore di una proprietà, come in questo esempio per il nostro oggetto Property.

public string CustomerID  
{  
    set  
    {  
        if ((this._CustomerID != value))  
        {  
            this.OnCustomerIDChanging(value);  
            this.SendPropertyChanging();  
            this._CustomerID = value;  
            this.SendPropertyChanged("CustomerID");  
            this.OnCustomerIDChanged();  
        }  
     }  
}

partial class Customer
    {  
        partial void OnCustomerIDChanging(string value)  
        {  
            //Perform custom validation logic here.  
        }  
    }

Ti potrebbe interessare anche: Codici in informatica: linguaggio fondamentale in informatica