Разработка слоя доступа к данным только для добавления приложений с помощью LINQ to SQL

Question

Я имею в виду приложение, которое предписывает таблицы базы данных только для добавления; то есть я могу только вставить данные в базу данных, но никогда не обновлять и не удалять их. Я хотел бы использовать LINQ to SQL для создания этого.

Поскольку таблицы предназначены только для добавления, но мне все еще нужно иметь возможность «удалять» данные, я думаю, что каждая таблица Foo должна иметь соответствующую таблицу FooDeletion. Таблица FooDeletion содержит внешний ключ, который ссылается на Foo, который был удален. Например, в следующих таблицах описывается состояние «Foos 1, 2 и 3 существуют, но Foo 2 и Foo 3 были удалены».

Foo      FooDeletion
id       id  fooid
----    -------------
1        1   2
2        2   3
3

Хотя я мог бы построить абстракцию поверх уровня доступа к данным, который (а) предотвращает прямой доступ к LINQ для объектов SQL и (б) управляет удалением таким образом, одна из моих целей - сохранить уровень доступа к данным как настолько тонкий, насколько возможно, поэтому я бы предпочел, чтобы DataContext или классы сущностей выполняли работу за кулисами. Итак, я хотел бы позволить вызывающим абонентам использовать Table<Foo>.DeleteOnSubmit() как обычно, и DAL знает, как добавить строку к FooDeletion вместо удаления строки из Foo.

Я прочитал «Реализация бизнес-логики» и «Настройка поведения вставки, обновления и удаления классов сущностей» , но не могу найти конкретный способ реализовать то, что я хочу. Я думал, что мог бы использовать частичный метод DataContext.DeleteFoo (), чтобы вместо этого вызвать ExecuteDynamicInsert (FooDeletion) , но в соответствии с этой статьей , «Если вызывается неприменимый метод (например, ExecuteDynamicDelete для обновляемого объекта), результаты не определены ".

Это глупое поручение? Я делаю это намного тяжелее для себя, чем мне нужно?

Answer 1

У вас есть несколько вариантов - вы можете:

a) Переопределить SubmitChanges, принять набор изменений (GetChangeSet ()) и перевести обновления и удаления во вставки.

b)Используйте вместо триггеров db-side для изменения поведения обновления / удаления.

c) Добавьте новый метод расширения расширения в таблицу, который реализует желаемое поведение.

d) ...или комбинируйте a + b + c по мере необходимости ...

Answer 2

если вам нужно решение для корпоративного качества для крупного мальчика, вы бы поместили его в базу данных - либо b) сверху, либо процедуры CRUD <- мое предпочтение ... триггеры - зло. </p>

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