Termenul „logica de afaceri“ în această secțiune se referă la orice reguli personalizate sau inspecții, care sunt aplicate datelor înainte ca acestea sunt introduse, actualizate sau șterse din baza de date. Logica de afaceri este, de asemenea, denumite uneori prin termenii „regulile de business“ sau „logica de domeniu“. Aplicațiile multi-tier logica de afaceri este implementat ca un nivel logic, și poate fi modificat în mod independent, din stratul de acces stratul de prezentare și de date. logica de afaceri poate fi numit nivelul de acces la datele înainte de actualizare, insera sau șterge datele din baza de date sau după aceste operații.
Logica de afaceri poate fi un simplu circuit de verificare de compatibilitate câmp de tip cu tipul coloanei. Acesta poate consta, de asemenea, dintr-un set de obiecte care interacționează mod arbitrar și destul de complicată. Regulile pot fi implementate sub forma unor proceduri stocate pentru baza de date sau ca obiecte conținute în memorie. Indiferent de metoda de punere în aplicare logica de afaceri LINQ tehnologie SQL permite utilizarea claselor parțiale și metode pentru separarea logicii de afaceri de la codul de acces la date.
În cazul în care, în timpul dezvoltării, fie manual, fie folosind obiect constructor Designer relational sau program SQLMetal creează o clasă de entitate, este definită ca o clasă parțială. Acest lucru înseamnă că, într-un fișier separat cu codul sursă, aveți posibilitatea să atribuiți o altă parte din clasa entitate care conține o logică de afaceri personalizate. La momentul compilării, cele două părți sunt combinate într-o singură clasă. Cu toate acestea, dacă doriți să re-crea clasa entitate folosind obiect constructor Designer relational sau program SQLMetal, acest lucru se poate face fără a schimba partea care conține logica de afaceri.
clase parțiale care definesc esența, și clase DataContext conțin metode comune. Aceste metode sunt puncte de extensie care pot fi folosite pentru a aplica logica de afaceri înainte de a actualiza, introducerea sau scoaterea unei entități sau entitate proprietăți, și după aceste operații. Metodele parțiale pot fi considerate ca un eveniment de compilare-timp. Generatorul de cod determină semnătura metodei și aceste metode în metodele accesoare de proprietate „get“ și „set“, designerul DataContext și, în unele cazuri, în mod implicit atunci când apelați metoda SubmitChanges. Cu toate acestea, dacă nu pune în aplicare o anumită metodă parțială, toate trimiterile la aceasta sunt eliminate, iar definiția la momentul compilarii.
În anumite implementări, create într-un fișier separat cu codul sursă, puteți efectua orice logica personalizată necesară. Acesta poate fi folosit ca un domeniu de clasă parțială și a determina cauza metodei sale de realizare parțială într-o instalație sau instalații separate. În orice caz, logica de afaceri este complet separat de codul ca un strat de acces la date, și din codul stratului de prezentare.
Următorul exemplu ilustrează o parte din codul creat cu Object Relational Designer pentru clasa DataContext. care conține două tabele: clienți și comenzi. Vă rugăm să rețineți că metodele de „Insert“, „Update“ și „Delete“ sunt definite pentru fiecare tabel în clasă.