Универсальные Типы по сравнению с Абстрактным классом / Интерфейсы
У Вас есть несколько проблем здесь, которые не имеют отношение хорошо друг к другу.
На основном уровне базы данных можно отследить изменения при наличии отдельной таблицы, которая добавила запись к нему через, включает, ВСТАВЛЯТЬ/ОБНОВЛЯТЬ/ОПЕРАТОРЫ УДАЛЕНИЯ. Это - общий способ отследить изменения в таблице базы данных.
другая вещь, которую Вы хотите, состоит в том, чтобы знать, который пользователь внес изменением. Обычно Ваши триггеры не знали бы это. Я предполагаю что, если Вы хотите знать, какой пользователь изменил часть данных тогда его возможное, что многочисленные пользователи могли изменить те же данные.
нет никакого правильного способа сделать это, Вы, вероятно, захотите иметь отдельную таблицу, что Ваш код приложения вставит запись в то, каждый раз, когда пользователь обновляет некоторые данные в другой таблице, включая пользователя, метку времени и идентификатор измененной записи.
Удостоверяются, что использовали транзакцию, таким образом, Вы не заканчиваете со случаями, где обновление обходится без вставка, или если Вы делаете противоположный порядок, Вы не заканчиваете со вставкой без обновления.
2 ответа
Думаю, вы немного запутались. Универсальные типы и абстрактные классы / интерфейсы служат разным целям для разных подходов к разработке приложений. Абстрактные классы / интерфейсы предназначены для обобщения общих функций группы объектов. Позже этот API может быть реализован по-другому, но поскольку присутствует полиморфизм, он ни на кого не повлияет.
С другой стороны, иногда у вас есть очень похожая реализация чего-то, и единственная разница заключается в типе объектов, с которыми вы работаете. Здесь вам понадобится универсальный. Вы можете использовать полиморфизм, но в этом нет необходимости. Для этой цели гораздо понятнее просто определить интерфейс, реализовать его и позволить конечному пользователю решать, какой тип объекта использовать.
Лучшим примером является List, где основная цель list - хранить элементы. Разработчику List не важно, какой тип объектов вы собираетесь использовать, поэтому позже вы сможете просто определить List и использовать целочисленный список.
Поскольку в вашем случае элемента управления "дерево" определение универсального элемента управления "Дерево" будет означать, что элементы дерева могут быть любого типа (вы также можете добавить определенные ограничения).
При создании экземпляра элемента управления , вам, конечно, придется объявить свой тип элемента (как во втором примере кода с IItem и BaseClass ).
Если бы ваш элемент управления Tree не был универсальным типом , вам нужно будет создать несколько элементов управления для каждого типа элемента.
Почему бы просто не использовать тип interface / abstractBase?
Если бы вы просто использовали интерфейс / абстрактный в качестве конкретного класса элемента, вы были бы ограничены его определением . Вы увидите только его свойства и методы. С помощью общего элемента управления Tree и любого типа элемента вы по-прежнему можете получить доступ ко всем элементам.