创建可重用企业名称空间的最佳实践

本文关键字:最佳 空间 企业名 创建 | 更新日期: 2023-09-27 18:09:31

好吧,我已经想了一段时间了。我正在为所有常见的中间层对象创建一个可重用的公司名称空间(类库)。然后,我们的任何开发人员都可以在其项目的开发阶段引用该程序集。这是我的问题。是创建一个包含所有中间层逻辑的程序集更容易接受,还是将这个功能分解成更小的程序集?

示例:单个程序集(命名空间示例)

系统

系统。IO

System.IO.RegEx

系统。净

System.Net.Mail

系统。安全

系统。Web - AssemblyFull.dll

示例:Multiple Assemblies

系统。IO

先。Reg - 编译为AssemblyIO.dll

系统。净

系统。Net - 编译为AssemblyNet.dll

在过去,我已经使用这两种方法,但我想知道其他人怎么做,为什么?我不是在寻找任何代码示例,我只是想知道其他开发人员在做什么?

提前感谢。

创建可重用企业名称空间的最佳实践

作为一般规则,如果程序集不是显式耦合的,我将它们分开。例如,如果你有一个低级的网络API,和其他用于FTP相关操作的API,后者可能依赖于前者;但对于API用户,你的开发者;没有必要把两者都放在一个会议上;也许一个项目不需要FTP API,所以他们只需要包括核心的"Net"程序集。您可以分离api,以便尽可能地实现原子化,并避免开发人员在只使用其中一小部分的情况下包含一个大的程序集。

这种方法的缺点是,如果开发人员需要FTP程序集,他们还需要包括Net程序集;因此,您必须找到一种方法来管理这些依赖关系,从而降低开发人员的复杂性。在做Java应用程序时,我使用Maven(来自Apache),但到目前为止,我还不知道一个好的。net类Maven替代方案。

但是如果你正在为你的公司构建一些api,使用Wiki站点或其他轻量级文档工具你可以解决这个问题。

我不认为这是一个正确的答案,但我倾向于对我们所有的库使用一个通用的命名方法。

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

网络。信用卡
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

所以不管你的建筑是什么类型的项目,你都可以重用它们,并很快地识别它们。其中一些有自己的接口,可以根据项目需求继承和重载以添加更多功能。

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

:

我需要确定哪些业务/中间层对象将在所有向前推进的项目中使用。一旦这些已经确定,我将创建一个程序集[company].common[company].common.util。这些将被我们当前和即将到来的项目所参考。

第二:

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

第三:

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

我想感谢大家这么快就给我回复。这是我在SO上的第一个帖子,但我可以向你保证,你很快就会在这里再次看到我。再次感谢。

对于可重用文件,我使用了不同的方法。

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

每个可重用的"东西"(类、函数、UserControl、图标等)都在一个单独的文件中。

需要可重用部分功能的项目直接链接到源文件。("添加现有项目"、"添加为链接")。为了方便,我将所有重用的部件放在VS的"实用程序"文件夹中(由于文件被链接,真正的实用程序文件夹是空的)

这个设置允许我:

  • 只需添加我需要的通用功能
  • 没有额外的依赖
  • 工具中的错误修复将自动包含在下一个构建

唯一的缺点是,如果你需要手动添加任何依赖的添加功能(例如,另一个可重用的组件或程序集)

因为我没有使用不同的程序集,所以命名空间只遵循函数:

  • 公司。公用工程
  • Company.Utilites.WPF
  • Company.Utilites.IO