.NET механизм безопасности для ограничения доступа между двумя типами в одном проекте?

Question

Вопрос

Есть ли в .NET Framework механизм, позволяющий скрывать один пользовательский тип от другого без использования отдельных проектов / сборок? Я не говорю о модификаторах доступа, чтобы скрыть членов Типа от другого типа - я имею в виду скрыть сам Тип.

Фон

Я работаю над проектом веб-сайта ASP.NET, и команда решила не использовать отдельные сборки проекта для разных уровней программного обеспечения. Поэтому я ищу способ иметь, например, папку DataAccess /, в которой я запрещаю его классам обращаться к другим типам в том же проекте веб-сайта ASP.NET. Другими словами, я хочу подделать слои и иметь какой-то механизм безопасности вокруг каждого слоя, чтобы он не мог получить доступ к другому.

Подробнее и подробности ...

Очевидно, что нет способа применить это ограничение, используя ключевые слова OO для конкретного языка, поэтому я ищу что-то еще, например: возможно, структуру доступа или механизм доступа к коду, может быть что-то, что использует метаданные, такие как Атрибуты. Даже то, что ограничивает одно пространство имен от доступа к другому. Я не уверен, какую окончательную форму он может принять.

Если бы это был C ++, я бы, вероятно, использовал бы friend в качестве решения, которое в данном случае не переводится в C # internal, хотя их часто сравнивают.

Мне все равно, действительно ли решение скрывает Типы друг от друга или просто делает их недоступными; однако я не хочу блокировать один тип из всех других, другая причина, по которой модификаторы доступа не являются решением. Ответа времени выполнения или времени разработки будет достаточно. Ищете что-то простое для реализации, иначе это не стоит усилий ...

Answer 1

Вы можете использовать NDepend для этого:

http://www.ndepend.com/

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

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

Обновление

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

• Если люди не обладают невероятной дисциплиной,сборка будет ломаться при нарушениях наслоения.
• В файле проекта VS будет происходить слияние контроля исходного кода - не приятно.
• Ваша единица повторного использования очень велика и не определена, если выХотите поделиться сборками с другими приложениями \ проектами, которые вы разрабатываете.Это может привести к очень нежелательному сцеплению.

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

Answer 2

ничего из коробки;могут быть некоторые сторонние инструменты, которые вы можете использовать для объединения некоторых правил, основанных, возможно, на пространствах имен и т. д. Что-то вроде настраиваемого правила fx cop ...