公司内的类库/共享库开发？

Question

在中小型网络开发公司（约50名员工）中，是否有关于开发类库（自定义内部“企业库”）或具有多个项目的共享源项目或解决方案的指南/最佳实践吗

目前有一个项目包含所有“可重复使用”的代码，可以包含在新项目中。该项目到目前为止并不“重”，但代码也没有逻辑连接，它只是一大堆先前创建的功能。 需要询问哪些问题才能确定这是否是一种好方法？

Answer 1

听起来你有大型装配，其中包含所有共享功能（如果我错了，请纠正我）。

与大多数事情一样，这种方法的好处和负面因素取决于您的需求。

在（“过时的”但可能仍然相关）文章Improving Managed Code Performance中，实际上建议“更喜欢单个大型装配而不是多个较小的装配”。我不确定是否会有任何性能影响。如果它们引人注目，我认为它只会在启动时。

即使您的所有代码都在一个程序集中，为了便于使用，我建议将功能区域逻辑分区为单独的命名空间。你对“桩”一词的使用似乎意味着可能并非如此。

积极的一面：

• 添加对单个程序集的引用很容易
• 部署可能更容易，因为只需要部署一个程序集（更难搞乱？）
• 潜在的绩效改进

否定的一面：

• 如果90％的用户仅使用5％的实际功能，那么加载整个程序集可能并不“值得”
• 单个程序集可能会使执行架构/设计标准更难。例如如果UI层不应直接与数据层对话，那么公开共享数据访问功能可能没有意义。单个组件可以更容易地注意到这种“错误”。 “为什么要从UI引用数据访问程序集？”

正如我之前提到的，我认为比程序集的实际打包更重要的是该程序集中的功能的逻辑分组。在您的Enterprise.dll程序集中，我希望看到一些组织该功能的命名空间。例如Enterprise.Logging，Enterprise.Caching，Enterprise.Validation，Enterprise.DataAccess，Enterprise.Security等。

Answer 2

开发类库的指南/最佳实践： http://msdn.microsoft.com/en-us/library/ms229042.aspx

你能澄清一下吗？当你说“......它只是一大堆先前创建的功能”时，你究竟是什么意思。“