Проектирование уровня доступа только для приложений с 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.

Я прочитал "Implementing Business Logic" и "Customizing the Insert, Update, and Delete Behavior of Entity Classes", но я не могу найти конкретный способ реализовать то, что я хочу. Я думал, что могу использовать метод DataContext.DeleteFoo(), чтобы вместо этого вызвать ExecuteDynamicInsert(FooDeletion), но в соответствии с this article: «Если вызывается неприменимый метод (например, ExecuteDynamicDelete для объекта, подлежащего обновлению), результаты не определены».

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

Answer 1

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

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

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

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

d) ... или скомбинировать а + Ь + с в случае необходимости ...

Answer 2

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

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