我有一个 C# .Net 解决方案集合，最初是作为概念证明，已经发展到近 15 个不同的项目。我目前正在重写整个产品系列，并尝试通过面向未来的组织，尽我所能保持最佳实践。
我已经进行了一些研究，但我仍然不清楚在多项目产品中保留代表的最佳位置，以最大程度地减少未来需要重构的可能性。
我假设普遍的共识是您将它们放置在对用例有意义的任何地方，但总的来说，我认为有一种最佳方法可以在解决方案中构建所有内容，以最大限度地减少问题、促进积极的模块化并简化维护。
在许多情况下，建议他们在使用他们的地方旅行；大概在类文件上方的命名空间中声明，在我的情况下，它将转换为我的公共库，其中包含强制事件的公共接口。我目前在他们自己的文件中有代表，在“代表”命名空间中。我这样做是否存在疏忽，或者我是否使代表的用例过于复杂 - 或者这是否符合当前的使用预期？
我已经完成了典型的搜索，但没有找到任何可信或实质性的东西；然而，这可能是关键字选择不当的结果。
我假设普遍的共识是您将它们放置在对用例有意义的任何地方，但总的来说，我认为有一种最佳方法可以在解决方案中构建所有内容，以最大限度地减少问题、促进积极的模块化并简化维护。
嗯，是的，在一般情况下，你可以把所有东西放在你喜欢的任何地方。但是，当您在团队中工作时，问题就开始了。在团队中，其他人必须了解程序的结构才能有效地创建代码。这意味着一致性，这是最终目标。
所以，这不仅仅是直觉的问题。在我工作过的所有公司中，我都是从编写编码标准开始的，并在各地积极执行。在这个编码标准中，我通常会提出大量的好/坏做法，包括线程、静态使用、变量/类的放置等。
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) 可能会使您的应用程序膨胀，其中包含很少或没有用途的小文件，这会使其他开发人员感到困惑。