创建可重用的公司命名空间的最佳实践

Question

好的，这个问题已经在我脑海里挥之不去了。我正在创建一个可重复使用的企业命名空间（类库），用于所有常见的中间层对象。这个程序集可以被我们任何开发人员引用，在他们的项目开发阶段使用。这是我的问题。是创建一个包含所有中间层逻辑的单一程序集更可接受，还是将这个功能拆分成较小的程序集？

示例：单一程序集（命名空间示例）

System

System.IO

System.IO.RegEx

System.Net

System.Net.Mail

System.Security

System.Web - AssemblyFull.dll

示例：多个程序集

System.IO

System.IO.Reg - 编译为 AssemblyIO.dll

System.Net

System.Net - 编译为 AssemblyNet.dll

过去我使用了这两种方法，但我想知道其他人都在做什么以及原因是什么？我不需要任何代码示例，我只是想知道其他开发人员的做法。

先谢谢了。

- TCNS-Bob

---

如果程序集包含所有内容，它会有多大？您是否期望公司的项目使用所有常见功能？如果不是，您能否将其逻辑上分成相关的子单元（然后可以将其放入不同的程序集中）？ - Richard Ev

谷歌搜索重用/发布等价原则。 - driushkin

Richard - 这个完整的程序集将由数百个对象组成。大多数项目通常会使用暴露出来的功能的75％-85％，但仍然可能使用其他部分。我的最初想法是像你说的那样处理。将最常用的对象构建到一个公共程序集中，然后将其他对象分解为单独的单元。但另一方面，我可以看到一个单一的程序集如何使其他开发人员的生活更轻松。您只需要引用中间层程序集即可完成。我有一种感觉这是六分之一还是半打。 - TCNS-Bob

Driushkin - 感谢这个提示。我曾经与一个老的 PM 合作过，他向我介绍了这个。我面临的最大问题是，未来的开发人员将如何访问这些程序集。我希望尽可能地减少痛苦。我个人会为所有我的对象详细记录文档，以便下一个人了解每个对象的目的。我真的不认为有对或错的答案。您可以创建一个包含所有内容的单一程序集，也可以创建20个不同的程序集，每个程序集负责其自己的独特操作/任务。 - TCNS-Bob

Answer 1

作为一般规则，如果程序集之间没有显式的耦合关系，我通常会将它们分开。例如，如果您有一个低级别的网络API和另一个用于FTP相关操作的API，后者可能依赖于前者；但对于API用户，也就是您的开发人员来说，没有必要在单个程序集中同时拥有两者；也许一个项目不需要FTP API，因此他们只需要包含核心的“Net”程序集。您可以将API分离以尽可能地原子化，并避免开发人员在仅使用其中一小部分时包含大型程序集。

这种方法的缺点是，如果开发人员需要FTP程序集，他们还需要包含Net程序集；因此，您必须找到一种管理这些依赖关系的方法，以减少开发人员的复杂性。我在编写Java应用程序时使用Maven（来自Apache），但至今我还不知道.NET的好类似Maven的替代方案。

但是，如果您正在为公司构建一些API，并且具有Wiki站点或其他轻量级文档工具，则可以解决此问题。

- Lorenzo Solano Martinez

---

Lorenzo - 感谢您的快速回复。这是我第一次听说Maven，听起来很酷。越想越觉得拆分我的对象是最有意义的。尽可能地将它们分开。如果其中一个开发人员需要访问电子邮件功能，确实没有理由让加密对象可见/可访问。感谢大家的快速回复，我真的很感激从别人那里获取意见。另外我看到我不是唯一在星期天工作的人。 - TCNS-Bob

@lorenzo NuGet（www.nuget.org）是在.NET上最接近Maven的工具。 - x0n

Answer 2

我认为这个问题没有一个正确的答案，但我倾向于为我们所有的库使用一种通用的命名方法。

我有一个库来处理大量的中间层功能，就像大多数应用程序都会使用的常见任务。

Web.CreditCard
Web.CreditCard.Authorization
Web.CreditCard.Charge
Web.CreditCard.Batch

Web.Store.Order
Web.Store.Entities
Web.Store.Cart
Web.Store.Auth

Web.User.Auth.OpenID
Web.User.Auth.OAuth
Web.User.Account
Web.User.Preferences

所以无论您正在构建哪种类型的项目，都可以重复使用它们并快速识别它们。其中一些具有自己的接口，并且可以被继承和重载以根据项目要求添加更多功能。

- Michael D. Irizarry

---

这几乎就是我们代码库中所需要的。我只是想让其他开发人员能够更轻松地使用它。我将继续使用一个通用程序集，用于所有项目，然后为不太常见的功能使用单独的程序集。非常感谢那些迅速回复我的人，我真的很感激。 - TCNS-Bob

Answer 3

感谢回答这个问题的每一个人。由于每个项目都不同，几乎不可能得出正确的答案，我将描述我如何处理这个问题。

首先：

我需要确定哪些业务/中间层对象将在所有未来的项目中使用。一旦确定了这些对象，我将创建一个程序集 [公司].common 或 [公司].common.util。这些将被引用到我们当前和即将推出的所有项目中。

其次：

确定更具体项目的对象。这些程序集可能会被引用，也可能不会被引用。例如 [公司].security.cryptography。

第三：

确保每个对象都有良好的文档，以便未来的开发人员拥有必要的知识来正确维护和引用正确的程序集。

我想感谢每个人对我的快速回复。这是我在SO上的第一篇帖子，但我可以向你保证，你很快就会再次看到我。再次感谢。

- TCNS-Bob

---

我个人不喜欢在命名空间中使用公司名称，我曾经与Verizon合作过，许多命名空间都是Verizon.[Name]，现在该公司的一部分已经更名为其他名称，但该命名空间仍然存在。 - Michael D. Irizarry

有道理。通常我会使用公司名称，因为我们通常在执行某种形式的集成时，更容易识别程序集来自哪里。如果您要创建一个通用命名空间，您会使用什么作为顶级？ - TCNS-Bob

Answer 4

我使用了一种不同的方法来处理可重用文件。

我创建了一个单独的解决方案，其中包括所有可重用组件、测试等。

每个可重用的“东西”（类、函数、用户控件、图标等）都在一个单独的文件中。

需要从可重用部分获取某些功能的项目直接链接到源文件。（“添加现有项”，“作为链接添加”）。为了方便起见，我将所有重复使用的部分放在VS的“实用程序”文件夹中（真正的实用程序文件夹为空，因为文件是链接的）

这种设置使我能够：

• 只添加我需要的常见功能
• 没有额外的依赖关系
• 实用程序中的错误修复会自动包含在下一个构建中

唯一的缺点是，如果您需要手动添加任何依赖项，则添加的功能会得到（例如另一个可重用组件或程序集）

由于我不使用不同的程序集，所以命名空间只是遵循函数：

• Company.Utilites
• Company.Utilites.WPF
• Company.Utilites.IO

- adrianm