将常量移动到单独的程序集中

Question

5

我有一个项目使用了很多全局常量。最终我计划把程序的一些部分提取出来，创建自己的程序集。

创建一个仅包含全局常量的程序集（例如GlobalConstants.dll），这样我可以在将来的程序集中使用它，这样做是否值得（或者是否可能）？

这种方法将帮助我减少编码量，并且我可以在项目之间保持相同的常量名称。

- logeeks

3个回答

4

你认为有多少项目会使用相同的常量？如果确实有这样的情况，那很好；否则... 就不要使用它。

当然，如果你有一些同样可能被重复使用的实用库，那么它们可能在那里有意义，只要适当地由命名空间和类型进行范围限定。

就我个人而言，在没有实际、具体的目的要求移动它们之前，我会让它们保持原样。

- Marc Gravell

1

创建一个单独的常量程序集的原因之一是允许进行“较少复杂”的更新，例如错误消息和本地化，您可以通过热修补更新程序集并减少破坏其他内容的风险。

通常我们发现共享常量有用的地方是在业务实体层程序集中包含全局常量 - 因为业务实体是我们架构中唯一可被（大多数）层访问的层。

拥有一个单独的程序集会带来额外的开销，并且根据您拥有的常量，您可能会有一些直接依赖于功能的常量 - 例如，在Hashtable中查找值时可能使用的键。

- Russell

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Mikael Östberg · Accepted Answer

虽然这样做可能是可行的，甚至可能是一个很好的想法，但你应该知道C#编译器将常量视为值而不是引用。

我的意思是，C#编译器将在你的代码中替换所有常量的实例，并用值替换“变量”。

这意味着，即使你更新了程序集 GlobalConstants.dll 并将其复制到其中一个应用程序中，你仍需要重新编译该应用程序。否则，应用程序将使用旧的常量值。

为解决此问题，你可以简单地使用public static readonly而不是public const，因为readonly修饰符与const不同，它被C#编译器视为代码中的引用而不是值。