Что лучше всего делать при предоставлении классов из библиотеки, состоящей из нескольких сборок?

Я нахожусь в процессе создания библиотеки, которая должна использоваться различными приложениями. Эти приложения не должны видеть детали реализации библиотеки, а просто должны быть представлены с удобным интерфейсом.

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

Чтобы решить эту проблему, я создал несколько внутренних классов и методов, а затем пометил их сборки атрибутом InternalsVisibleTo в файле AssemblyInfo.cs. Это работает, как и ожидалось.

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

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

Какова наилучшая практика в этой ситуации?


person Chris    schedule 31.07.2014    source источник


Ответы (1)


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

О сборках друзей можно прочитать здесь. Основной вариант использования — модульное тестирование.

person Keith    schedule 31.07.2014
comment
Согласовано. Мы утверждаем, что InternalsVisibleTo используется только для модульных тестов (и даже это не одобряется). Одна из проблем с InternalsVisibleTo заключается в том, что он отключает предупреждение о неиспользуемых внутренних методах и классах. - person Matthew Watson; 31.07.2014