Реалізація бізнес-логіки (linq to sql)

Термін "бізнес-логіка" в даному розділі відноситься до будь-яких призначеним для користувача правилам або перевірок, які застосовуються до даних перед їх вставкою, оновленням або видаленням в базі даних. Бізнес-логіку також іноді називають термінами "бізнес-правила" або "логіка домену". У багаторівневих додатках бізнес-логіка реалізується у вигляді логічного рівня, і її можна змінювати незалежно від рівня представлення даних або рівня доступу до даних. Бізнес-логіка може викликатися рівнем доступу до даних перед оновленням, вставкою або видаленням даних в базі даних або після виконання цих операцій.

Бізнес-логіка може являти собою просту схему перевірки сумісності типу поля з типом шпальти таблиці. Вона також може складатися з набору об'єктів, що взаємодіють довільним і досить складним чином. Правила можуть реалізовуватися у вигляді збережених процедур для бази даних або в якості об'єктів, що містяться в пам'яті. Незалежно від способу реалізації бізнес-логіки технологія LINQ to SQL дозволяє використовувати колективні класи і методи для відділення бізнес-логіки від коду доступу до даних.

Якщо під час розробки або вручну, або за допомогою конструктора Object Relational Designer або програми SQLMetal створюється клас сутностей, він визначається як розділяється клас. Це означає, що в окремому файлі з вихідним кодом можна визначити іншу частину цього класу сутностей, що містить призначену для користувача бізнес-логіку. Під час компіляції обидві частини об'єднуються в один клас. Однак, якщо потрібно повторне створення класу сутностей за допомогою конструктора Object Relational Designer або програми SQLMetal, це можна зробити без зміни тієї частини, яка містить бізнес-логіку.

Спільні класи, які визначають сутність, і клас DataContext містять колективні методи. Ці методи є точками розширення, які можна використовувати для застосування бізнес-логіки перед оновленням, вставкою або видаленням суті або властивості сутності, а також після виконання цих операцій. Спільні методи можна розглядати як події часу компіляції. Генератор коду визначає сигнатуру методу і викликає ці методи в методах доступу до властивостей "get" і "set", конструкторі DataContext і в деяких випадках неявним чином при виклику методу SubmitChanges. Однак, якщо не реалізувати певний розділяється метод, всі посилання на нього і визначення видаляються під час компіляції.

У визначенні реалізації, створеному в окремому файлі з вихідним кодом, можна виконати будь-яку необхідну для користувача логіку. Можна використовувати розділяється клас як рівня домену або викликати його з визначення реалізації розділяється методу в окремому об'єкті або об'єктах. У будь-якому випадку бізнес-логіка повністю відокремлена як від коду рівня доступу до даних, так і від коду рівня представлення даних.

У наступному прикладі демонструється частина коду, створеного за допомогою Object Relational Designer для класу DataContext. який містить дві таблиці: Customers і Orders. Зверніть увагу, що методи "Insert", "Update" і "Delete" визначено для кожної таблиці в класі.