Предотвратите других разработчиков, использующих базовые методы в классе

У меня есть класс, который использует объекты файловой системы для управления данными. У нас есть несколько методов, специально предназначенных к (попытайтесь к), справьтесь с некоторыми проблемами, с которыми мы сталкиваемся с этим подходом (захват файла, несуществующие файлы, и т.д.). Идеально я хотел бы смочь выдать предупреждение, если другой разработчик делает попытку доступа файловая система непосредственно через Систему. IO вместо того, чтобы использовать вспомогательные методы.

Действительно ли это возможно? Поведение, которое я ищу, состоит в том, чтобы эффективно отметить методы, такие как Файл. ReadAllText (), как будто они были устаревшими, но только в рамках этого проекта (НЕ всего решения).

Я сделал некоторое рытье вокруг, и похоже, что моя единственная опция, "говорят им удостоверяться, что они используют Ваши методы". Я надеюсь, что кто-то может дать мне другой, и более полезный ответ.:)

- РЕДАКТИРОВАНИЕ - предложения пользовательского правила StyleCop или FxCop хороши, но к сожалению непрактичны в этом сценарии (не, каждый разработчик в отделе использует эти превосходные инструменты), и законные методы, которые делают, доступ к файлу действительно использует Систему. IO. Добавление "игнорирует" атрибуты к законным методам, опасная идея, также. Если кто-то будет видеть, как я "нарушил" свое собственное правило, они, вероятно, скопируют атрибут в свой собственный метод.

7
задан ZombieSheep 4 February 2010 в 15:14
поделиться

5 ответов

Используйте инструмент статического анализа (например, StyleCop или FxCop) с правилом , которое фиксирует "Не используйте System.IO напрямую". Затем интегрируйте его как часть вашего автоматизированного процесса сборки и вырвите, если кто-то попытается использовать System.IO напрямую. Никто не любит ломать сборку.

11
ответ дан 6 December 2019 в 21:13
поделиться

Вы можете написать правило пользовательского анализа для анализа кода FxCop / Visual Studio и запускать его как часть вашей автоматической сборки.

1
ответ дан 6 December 2019 в 21:13
поделиться

Чм. Не пробовал сам, а как заставить людей использовать пользовательские классы обработки файлов, используя псевдоним пространства имен, который «скрывает» подлинный System.IO. Если я правильно помню, они применяются на уровне проекта.

0
ответ дан 6 December 2019 в 21:13
поделиться

Можете ли вы добавить некоторые настраиваемые функции в ловушку фиксации исходного кода? Он не найдет существующих нарушений (если они есть), если эти файлы не будут изменены, но должен обнаружить новые применения?

Есть ли что-нибудь хорошее?

0
ответ дан 6 December 2019 в 21:13
поделиться

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

Разве это не то, что " Корпоративные шаблоны "предназначены для? Разве они не позволяют вам создать файл политики, который ограничивает разрешенные ссылки на проекты?

В качестве альтернативы, хотя это и не является надежным, не могли бы вы добавить в проект событие перед сборкой, которое выдает предупреждение, если имеется ссылка на System.IO?

0
ответ дан 6 December 2019 в 21:13
поделиться
Другие вопросы по тегам:

Похожие вопросы: