C# 确保封装的建议

在我的解决方案中，我有一个DLL项目，比如说

Project1

，它拥有一个类，比如

class a

。此类具有一些非常重要的属性，因此只能在此DLL中设置。引用此DLL的任何其他项目只能使用getter。到目前为止，我通过内部访问setter来处理这种情况，例如：

public class A
{
  int Num1 
  {
    get; 
    internal set;
  }

  int Num2 
  {
    get; 
    internal set;
  }
} 

现在，我必须向解决方案添加另一个项目，

Project2

，该解决方案不仅必须使用

class A

（getter和setter），而且，

Project1

还引用了这个新项目。因此，我决定在不同的定义dll中，在层次结构的顶部分离

类A

。这就是问题所在，我的问题解决了。现在所有的设置器对

Project1

和

Project2

都是不可见的。如果我删除

内部

访问器，则任何引用定义dll的程序集都可以使用setter。我不想这样做，因为

A类

上的信息非常重要，不能设置错误

我如何限制从

Project1

和

Project2

外部访问

class A

的设置者

---

我想到的唯一解决办法是使用

内部可视到
。我不知道，听起来并不完美。另外，结合
Project1
和
Project2
也是另一种解决方案，但这两种方案负责完全不同的任务，从设计角度来看，这不是最好的选择。
您总是可以做类似的事情（设计的噩梦，但按照您的要求去做）：

然后你可以正常地实例化这个类。。。当需要设置使用反射的值时：

myClassA.GetType().GetMethod ("SetNum", BindingFlags.NonPublic ).Invoke (myClassA, new object[] {1, 777 });

如果我正确地假设Project1做了一些特定的事情，而Project2是一个抽象，那么这是一个控制反转的候选者——理想情况下，一个实现应该依赖于抽象，而不是相反

如果Project2中的内容需要控制Project1中定义的内容，请在Project2中创建一个接口并让Project2与该接口对话，然后在Project1中实现该接口并在内部执行所有脏活。
您可以将内部保护器保留在其上，但可以信任另一个程序集访问内部成员

[assembly: InternalsVisibleTo("AssemblyName")]

可以在类级别执行此操作，如果需要，也可以在整个程序集本身上执行此操作

关于OP为什么对这个选项犹豫不决，有什么想法吗？这似乎非常适合。因为如果出现Project3，他需要重建包含类A的DLL，以添加Project3 InternalsVisibleTo子句…噢，对不起，没有更仔细地阅读问题的最后一句话。我认为，根据设计，InternalsVisibleTo仍然是最好的选择。您不希望授予对这些属性的全局访问权限，因此您希望准确地控制您信任哪些程序集使用这些属性。为每个新程序集添加新的InternalsVisibleTo属性是DesignWise的最佳方式我支持您。。。实际上，我并不认为OP想要这样做：-（@Gabriel:InternalsVisibleTo属性似乎是一个很好的解决方案，它需要为每个使用类a的项目重建dll。我只是想看看是否还有其他选择。
[assembly: InternalsVisibleTo("AssemblyName")]