共享程序集

Question

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

我采访过的一些人相信以下内容：应用程序应该是孤岛。他们应该分享一切。不共享程序集，组件或数据库。

我需要这方面的建议。何时可以分享，或者它永远不是一个好主意。

由于

Answer 1

有一条线，某处......积极鼓励共享库代码 - 但是当应用程序彼此消耗时，你需要小心谨慎，只是为了防止意大利面条代码和循环引用

如果你提到的代码真的是库代码（即这两个项目都不是这个数据的“主”），那么它应该没问题（抛开版本问题）。如果项目A想要项目B的数据，那么通常不久之后项目B需要项目A的数据，并且你有一个蜘蛛网。在这种情况下，最好使用SOA方法;让项目通过类似WCF服务的方式公开他们的数据，以便其他项目只调用公共mex / wsdl API（理想情况下没有汇编共享）。

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

Answer 2

这不是集会的“dll”的全部意义吗？分享一些事情......

为什么在可以在程序集中共享内容时创建和双重维护代码？

Answer 3

我会说只分享设计和打算分享的内容。

大多数时候，我发现代码共享只是出于懒惰，也就是说，共享完全没有设计的代码，也不需要共享代码。这几乎总是在以后需要更改原始代码时出现问题并且没有简单的方法来执行此操作，因为代码旨在从一个位置使用而不是几个因此设计师没有' t应对多个“用户”扩展的可能性。

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

这不仅适用于程序集，也适用于类，资源或项目的任何其他部分。这就是设计如此重要的原因，因为事先已经考虑过您已预见到大多数可能的并发症，因此共享的影响已被量化和限制，以便分享费用低于优惠。如果您急于分享事物而不考虑后果，那么您的代码将不会为此做好准备，因此调整共享代码或相关共享问题的成本将远高于任何可能的好处。

Answer 4

您应该分享所有内容（当然，在常识范围内）。您是一个开发人员团队，而不是一组个人开发人员。共享代码有许多好处：可重用性意味着更快的开发，更简单的维护（您只需要修复一次错误），新功能或改进可能立即使所有依赖项目受益，这也意味着分享想法。就个人而言，我从同事的源代码中学到了一些技巧和良好实践。

Answer 5

使用dll共享代码的好处是，您只需编写一次代码即可。如果每个应用程序都是一个孤岛，那么你必须保留相同代码的多个副本，因此必须在许多地方修复相同的错误。

然而，应用程序之间共享代码会带来一系列问题。在您共享代码的瞬间，您会遇到需要该共享代码的不同版本的不同应用程序的问题。这通常称为dll hell。甚至.NET--其系统允许同一个dll的多个版本在系统上共存 - 并不能解决所有问题。除非您能够让所有客户了解所有产品，否则您仍然可能会遇到必须对同一个dll的不同版本进行相同更改的情况。

这个没有正确的答案。孤岛和分享都给他们带来了问题。

编辑：

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

Answer 6

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