C# 共享程序集

A我有一个设计问题。我已经写了几个c#应用程序。大多数应用程序都有自己的sql或access数据库，但它们也共享一个公共数据库，但它们是完全不同的应用程序，在各自的业务领域中有各自的职责

与我交谈的一些人认为：应用程序应该是筒仓。他们不应该分享任何东西。不共享程序集、组件或数据库

我需要这方面的建议。什么时候分享是可以接受的，还是永远都不是一个好主意

---

谢谢

这不是assambly“dll”的全部要点吗？分享东西

---

既然可以在程序集中共享东西，为什么还要重新创建和双重维护代码？

你应该共享所有东西（当然要在常识的范围内）。你是一个开发团队，而不是一组独立的开发人员。共享代码有很多好处：可重用性意味着更快的开发、更简单的维护（只需修复一次bug），新功能或改进可能会立即使所有相关项目受益，这也意味着共享想法。就我个人而言，我从同事编写的源代码中学到了一些技巧和良好做法。

使用dll共享代码的好处在于，您只需编写一次代码。如果每个应用程序都是一个思洛存储器，那么您必须保留相同代码的多个副本，因此必须在许多地方修复相同的bug

然而，在应用程序之间共享代码会带来一系列问题。共享代码的那一刻，您就遇到了不同的应用程序需要不同版本的共享代码的问题。这通常被称为。即使.NET系统允许同一dll的多个版本在一个系统上共存，也不能解决所有问题。除非您可以让所有客户都了解所有产品的最新信息，否则您仍然可能会遇到必须对同一dll的不同版本进行相同更改的情况

在这个问题上没有正确的答案。筒仓和共享都会带来问题

编辑：

---

如果您指的是在筒仓中工作而不共享代码的团队，那么DrJokepu是对的：在个人和团队之间共享开发工作是一个明确的“必须做的事情”。

有一条线，在某处。。。共享库代码是积极鼓励的——但当应用程序相互消耗时，你需要稍微小心一点，只是为了防止意大利面代码和循环引用

如果您提到的代码实际上是库代码（即，两个项目都不是此数据的“主控”），那么应该可以（版本控制问题除外）。如果项目A需要项目B的数据，那么项目B需要项目A的数据的时间通常不长，而且你有一个蜘蛛网。在这种情况下，最好使用SOA方法；让项目通过类似WCF服务的方式公开其数据，以便其他项目只调用公共mex/WSDLAPI（理想情况下没有程序集共享）

---

但这是一个看似复杂的问题，我不认为任何单一的答案都能满足每种情况。

跨应用程序共享程序集仅从理论角度讲是有意义的。实际上，它带来了一大堆问题。避免程序集共享，在本地部署所有程序集。

我想说的是只共享设计和打算共享的程序集。

大多数时候，我发现代码共享只是出于懒惰，也就是说，共享的代码根本不是为共享而设计的，也不是为共享而设计的。这几乎总是会导致以后需要更改原始代码时出现问题，而且没有简单的方法可以做到，因为代码是从一个位置使用的，而不是从几个位置使用的，因此设计师没有处理多个“用户”扩展的可能性

另一方面，您可能会想到，您正在设计要共享的东西，例如通信库、加密库或整个.NET framework。在这种情况下，共享是理想的，它将提高可维护性和代码重用，因为设计从一开始就涵盖了这一点

---

这不仅适用于程序集，还适用于类、资源或项目的任何其他部分。这就是为什么设计如此重要的原因，因为事先考虑过它你已经预见到了大多数可能的复杂性，因此共享的影响已经被量化和限制，因此共享的成本低于收益。如果您在没有考虑后果的情况下仓促地进行共享，那么您的代码将不会为此做好准备，因此调整代码以进行共享的成本或共享的相关问题将远远高于任何可能的好处

他说的是部署，不是开发（我想），如果他说的是开发，我不会感到惊讶。有很多“奇怪”的软件商店，他们用“替代”的方法来开发实践；这并不意味着“永远不要做”-我只是说“要意识到问题”