Запретить другим разработчикам использовать базовые методы в классе - PullRequest
7 голосов
/ 04 февраля 2010

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

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

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

- EDIT-- Предложения по использованию пользовательского правила StyleCop или FxCop хороши, но, к сожалению, нецелесообразны в этом сценарии (не каждый разработчик в отделе использует эти превосходные инструменты), и законные методы, которые делают доступ к файлу do , используют System. IO. Добавление атрибутов ignore к легальным методам тоже опасная идея. Если кто-то увидит, как я «нарушил» собственное правило, он, скорее всего, скопирует атрибут в свой метод.

Ответы [ 5 ]

11 голосов
/ 04 февраля 2010

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

1 голос
/ 04 февраля 2010

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

0 голосов
/ 04 февраля 2010

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

Хорошо?

0 голосов
/ 04 февраля 2010

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

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

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

0 голосов
/ 04 февраля 2010

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

...