将代表放在.Net解决方案中的位置[关闭]

Question

我有一个 C# .Net 解决方案集合，最初是作为概念证明，现已发展到近 15 个不同的项目。我目前正在重写整个产品系列，并尝试通过面向未来的组织，尽我所能保持最佳实践。

我已经进行了一些研究，但我仍然不清楚将代表留在多项目产品中的最佳位置，以最大程度地减少将来需要重构的可能性。

我认为普遍的共识是，您可以将它们放置在对用例有意义的任何位置，但总的来说，我认为有一种最佳方法可以在解决方案中构建所有内容，以最大限度地减少问题、促进积极的模块化并简化维护.

在许多情况下，建议他们在使用他们的地方旅行；大概在类文件上方的命名空间中声明，在我的情况下，这将转换为我的公共库，其中包含强制事件的公共接口。我目前在他们自己的文件中有代表，在“代表”命名空间中。我这样做是否存在疏忽，或者我是否使代表的用例过于复杂 - 或者这是否符合当前的使用预期？

我已经完成了典型的搜索，但没有找到任何可信或实质性的内容；但这可能是关键字选择不当的结果。

Answer 1

我认为普遍的共识是您将它们放置在任何地方 这对用例来说是有意义的，但总的来说我觉得有一个 在解决方案中构建所有内容以最小化问题的最佳方法， 促进积极的模块化，并简化维护。

嗯，是的，在一般情况下，你可以把所有东西放在你喜欢的任何地方。但是，当您在团队中工作时，问题就开始了。在团队中，其他人必须了解程序的结构才能有效地创建代码。这意味着一致性，这是最终目标。

所以，这不仅仅是直觉的问题；在我工作过的所有公司中，我都是从编写编码标准开始的，并在各地积极执行。在这个编码标准中，我通常会提出大量的好/坏做法，涉及线程、静态使用、变量/类的放置等。

Iirc 这个链接http://se.inf.ethz.ch/old/teaching/ss2007/251-0290-00/project/CSharpCodingStandards.pdf 和https://msdn.microsoft.com/en-us/library/ff926074.aspx 会给你一个良好的开端，虽然前者有点过时并且两者都没有真正回答你的问题。但是，从长远来看，它可能对您想要实现的目标有所帮助。

[...] 我目前有代表参加 他们自己的文件，在“委托”命名空间中。我有疏忽吗 这样做，还是我使用例过于复杂 代表 - 或者这是否符合当前的使用预期？

具有接口的通用库是有意义的。接口本质上是“客户端”和“服务器”之间的契约，是解耦软件的重要资产。

此时您必须意识到“接口”部分是功能分解，而不是技术分解。换句话说：您需要一个“接口”库这一事实是合同的问题，而不是技术结构的问题。因此，我不明白您为什么要将类放在“类”文件夹中，以及为什么要将代表放在“代表”文件夹中。简而言之，“代表”文件夹对我来说没有任何意义。把东西放在该放的地方。

此时，您需要做出决定。 （1）您可以将委托放在一个文件中，（2）您可以将委托放在使用它的类文件中（我通常将委托用于单一目的），（3）您可以根据单个 /多用途和（4）您可以将单用途委托嵌套在类中。这基本上意味着您将委托视为函数指针描述，而不是将其视为真正的“类”。

看看函数分解，你可以说函数指针属于一个类，就像方法一样。

因此得出结论。就我个人而言，我通常选择 (2) 或 (3) 选项，因为它简短、清晰、简洁，并且不会像 (4) 那样对“打字工作”的数量产生影响。选择 (1) 可能会使您的应用程序膨胀，其中包含很少或没有用途的小文件，这会使其他开发人员感到困惑。