.NET 安全机制限制同一项目中两种类型之间的访问？
问题
.NET Framework 中是否有一种机制可以在不使用单独的项目/程序集的情况下向另一种类型隐藏一种自定义类型？我不是在谈论从另一个类型隐藏类型成员的访问修饰符 - 我的意思是隐藏类型本身。
背景
我正在从事 ASP.NET 网站项目，团队决定不对不同的软件层使用单独的项目程序集。因此，我正在寻找一种方法来拥有一个 DataAccess/ 文件夹，我不允许其中的类访问同一 ASP.NET 网站项目中的其他类型。换句话说，我想伪造这些层，并在每个层周围都有某种安全机制，以防止它访问另一层。
更多信息和细节...
显然没有办法使用特定于语言的 OO 关键字来强制执行此限制，因此我正在寻找其他东西，例如：也许是权限框架或代码访问机制，也许使用属性等元数据的东西。即使是限制一个名称空间访问另一个名称空间的东西。我不确定它可能采取的最终形式。
如果这是 C++，我可能会使用 friend 作为解决方案，在这种情况下，它不会转换为 C# internal，尽管它们经常被比较。
我并不真正关心该解决方案是否实际上隐藏了彼此之间的类型，或者只是使它们无法访问；但是我不想锁定一种类型与所有其他类型，这是访问修饰符不是解决方案的另一个原因。运行时或设计时的答案就足够了。寻找一些容易实现的东西，否则不值得付出努力......
Question
Is there a mechanism in the .NET Framework to hide one custom Type from another without using separate projects/assemblies? I'm not talking about access modifiers to hide members of a Type from another type - I mean to hide the Type itself.
Background
I'm working in an ASP.NET Website project and the team has decided not to use separate project assemblies for different software layers. Therefore I'm looking for a way to have, for example, a DataAccess/ folder of which I disallow its classes to access other Types in the same ASP.NET Website project. In other words I want to fake the layers and have some kind of security mechanism around each layer to prevent it from accessing another.
More Info and Details ...
Obviously there's not a way to enforce this restriction using language-specific OO keywords so I am looking for something else, for example: maybe a permission framework or code access mechanism, maybe something that uses meta data like Attributes. Even something that restricts one namespace from accessing another. I'm unsure the final form it might take.
If this were C++ I'd likely be using friend to make as solution, which doesn't translate to C# internal in this case although they're often compared.
I don't really care whether the solution actually hides Types from each other or just makes them inaccessible; however I don't want to lock down one Type from all others, another reason access modifiers are not a solution. A runtime or design time answer will suffice. Looking for something easy to implement otherwise it's not worth the effort ...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用 NDepend 来执行此操作：
http://www.ndepend.com/
NDepend 可以允许您通过指定某些命名空间不应相互引用来强制执行“分层”规则。然后，您将 NDepend 和规则集插入到自动构建中，如果存在任何不当行为，构建将会失败（带有完整报告）。
通过这种方式，您可以在程序集中强制执行逻辑软件分层概念，而无需使用项目结构来实际执行。
更新
我昨晚深夜回答了这个问题，确切地说，就是如何直接解决这个问题。尽管可以使用工具来解决问题，但随着项目的发展，整个团队在一个项目中进行开发很可能会是一种非常痛苦的经历：
尽管我不提倡拥有大量微小的程序集，但围绕核心概念定义的合理数量是非常可行和可取的，例如“UI”、“数据访问”、“业务逻辑”、“公共库”和“共享类型”。
You could use NDepend to do this:
http://www.ndepend.com/
NDepend could allow you to enforce "layering" rules by specifying that certain namespaces should not reference each other. You then plug NDepend and the ruleset into your automated build, and it will fail the build (with a full report) if there are any misdemeanours.
In this way you can enforce logical software layering concepts within an assembly without having to use project structures to do it physically.
Update
I answered the question late last night, and rather literally i.e. how you can directly solve the question. Although a tool can be used to solve the issue, developing in one project across the whole team is more than likely going to be a pretty miserable experience as the project grows:
Although I do not advocate having lots of tiny assemblies, a sensible number defined around core concepts is very workable and desirable e.g. "UI", "data access", "business logic", "common library" and "shared types".
没有现成的东西；可能有一些第三方工具可以用来将一些规则组合在一起，可能基于命名空间等。类似于 自定义外汇警察规则...
Nothing out of the box; there may be some 3rd-party tools that you can use to kludge some rules together, based perhaps on namespaces etc. Something like a custom fx cop rule...