Реализация контрольного журнала с использованием нескольких таблиц

Question

В моих предыдущих приложениях я успешно настроил контрольный журнал с использованием подхода Paul Van Bladel's. Его подход работал отлично и с ним было очень легко следовать. Однако он использует только одну таблицу для хранения проверенных записей. Мне нужно сделать что-то подобное, за исключением того, что мне нужно иметь таблицу аудита для каждой из таблиц, которые будут проверяться, что составляет около 7-8 таблиц. Если бы я мог понять, как передать общие табличные объекты, я мог бы отказаться от решения Пола Ван Блэделя. Кто-нибудь знает о каких-либо других примерах, на которые я могу ссылаться? Или любые предложения о том, как правильно реализовать отслеживание аудита для нескольких таблиц.

p.s Я попытался использовать пример Beth Massi's, но, похоже, он не предназначался для использования в VS2012 Lightswitch, поскольку он не работает из коробки?

Answer 1

Ваш вопрос невероятно широк, потенциально слишком широкий. Из того, что я собираю, хотя у вас есть несколько таблиц, более чем вероятно с разными столбцами. Вы ищете общий подход, чтобы просто написать правильный контент на основе столбца без чрезмерного количества воспроизведения кода.

Что вы можете и должны сделать:

• Выпишите эти таблицы.
• Определить содержание, которое требуется для аудита.
• Сравните эти таблицы друг с другом.

Это часто помогает мне определить, в какой степени содержание должно быть абстрагировано. Этот конкретный пример может выиграть от Inversion Of Control или Инъекция зависимостей. Таким образом, вы можете ввести конкретные аудиторские проверки к конкретным Классы.

public interface IAudit<T> 
{ 
    void WriteToAudit(<T> model); 
} 

Так этот конкретный интерфейс будет реализовать Generic, который должен представлять модель данных аудита. Который может обеспечить несколько дифференцирующих моделей, чтобы лучше удовлетворить ваши требования, обеспечивая при этом гибкость.

Теперь вам нужно написать свои классы реализации, которые наследуют интерфейс.

public class Inventory : IAudit<InventoryModel> 
{ 
    public void WriteToAudit(InventoryModel model) 
    { 
      // Write your database content, then pass *Properties* from the model. 
      // Which will write for this particular table. 
    } 
} 

Теперь мощная часть этого подхода:

public class Stuff 
{ 
    private IAudit audit; 
    public void DoSomething(model) 
    { 
      audit.WriteToAudit(model); 
    } 
} 

Итак, теперь вы можете существенно создать новую IAudit, то вы можете пройти через несколько подходов:

• Конструктора
• Метод

Это невероятно грубая реализация, и у меня может быть несколько опечаток. Это был быстрый пост, но, надеюсь, это указывает на правильное направление. Более подробно по этому вопросу можно найти here.

Answer 2

Одним из вариантов, который вы можете рассмотреть, является обновление структур таблиц, чтобы обеспечить управление версиями строк в качестве альтернативы внешней таблице аудита.Эта схема очень полезна, когда вам нужен полный контрольный журнал и возможность выполнять анализ линии данных. Другим преимуществом этого является отчетность - вы можете допросить состояние данной записи в определенный момент времени - очень полезно для создания таблиц фактов или сохранения состояния при медленно меняющихся измерениях. Мой предпочтительный подход для этого - использовать что-то в соответствии с шаблоном SCD Type 2. (Общая идея.) here.)

Для каждой таблицы, на которой вы реализуете этот шаблон, измените запрос по умолчанию, чтобы возвращать активную запись - то есть фильтр для DateTo IS NULL. Тогда все, что вам нужно сделать, это перехватывать стандартные CRUD событий для удаления и обновления следующим образом: Table_Updating():

1. Скопируйте обновленный объект (содержащий все изменения) в новый локальный объект объект звукозаписывающей , (например, объект Order) Убедитесь, что поле ToDate равно null, а FromDate - DateTime.Now
2. Добавить локальный объект в коллекцию Entity с помощью метода Add (например, добавить новый объект Order в коллекцию Orders с помощью параметра Orders.Add (NewOrder метод).
3. Получить крюк к существующей копии записи объекта. (т.е. получить объект заказа соответствие цели OrderID где ToDate Is NULL)
4. Обновление существующей копии записи объекта и установить Todate в DateTime .Теперь
5. Зафиксируйте изменения

Table_Deleting():

1. Обновление ToDate на целевой записи в DateTime.Now вместо NULL
2. Удалить объект из коллекции измененных образований
3. Зафиксируйте изменения

Таблица_Интересность():

1. Убедитесь, что для поля DateFrom установлено значение DateTime.Now, поле DateTo равно NULL
2. Зафиксируйте изменения.

Всё.