我有一个C＃.Net解决方案集合，这些解决方案始于概念验证，并已发展到近15个不同的项目。我目前正在重写整个产品系列，并尽力保持最佳实践，以及面向未来的组织。
我做了一些研究，我仍然不清楚将代表留在多项目产品中的最佳位置，以尽量减少将来需要重构的可能性。
我认为普遍的共识是，您将它们放在对用例有意义的任何地方，但总的来说，我觉得有一种最佳方法可以在解决方案中构建所有内容，以最大限度地减少问题，促进积极的模块化，并简化维护。
在许多情况下，建议他们在使用的地方旅行;可能在类文件上面的命名空间中声明，在我的情况下，它将转换为我的公共库，其中包含用于命令事件的公共接口。我目前在他们自己的文件中有一个代表，在一个＆＃39;代表＆＃39;命名空间。我这样做是否存在疏忽，或者我是否对代表的用例过于复杂 - 或者这是否符合当前的使用期望？
我做过典型的搜索，但没有找到任何可靠或实质性的内容;但这可能是关键字选择不佳的结果。
答案 0 :(得分：2)
我认为普遍的共识是你把它们放在任何地方 这对用例有意义，但总的来说我觉得有一个 在解决方案中构建所有内容以最小化问题的最佳方法， 促进积极的模块化，并简化维护。
嗯，是的，在一般情况下，你可以把所有东西放在任何你喜欢的地方。但是，当您在团队中工作时，问题就开始了。在团队中，其他人必须了解程序的结构才能有效地创建代码。这意味着一致性，这是最终目标。
所以，这不仅仅是直觉问题;在我参与过的所有公司中，我开始编写编码标准并在各地积极执行。在这个编码标准中，我通常会提出大量的好/坏做法，包括线程，静态使用，变量/类的放置等。
Iirc此链接http://se.inf.ethz.ch/old/teaching/ss2007/251-0290-00/project/CSharpCodingStandards.pdf和https://msdn.microsoft.com/en-us/library/ff926074.aspx会给你一个良好的开端，虽然前者有点过时，但都没有真正回答你的问题。然而，从长远来看，它可能有助于您实现的目标。
[...]我目前有代表参加 他们自己的文件，在'delegate'命名空间中。我有疏忽吗？ 通过这样做，或者我使用例过于复杂 代表 - 或者这是否符合当前的使用期望？
具有接口的公共库是有意义的。接口本质上是“客户端”和“服务器”之间的契约，这是解耦软件的重要资产。
此时你必须意识到'界面'部分是功能分解，而不是技术分解。换句话说：您需要一个“接口”库的事实是合同，而不是技术构造。因此，我不明白为什么你会把类放在'classes'文件夹中，为什么你要把代理放在'delegates'文件夹中。简而言之，'delegates'文件夹对我没有任何意义。把东西放在它所属的地方。
此时，您有决定。 （1）您可以将委托放在一个文件中，（2）您可以将委托放在使用它的类文件中（我通常将委托用于单一目的），（3）您可以根据单个目的使用委托多用途和（4）你可以把单一用途的代表嵌套在类中。这基本上意味着您将委托视为函数指针描述，并且不将其视为真正的“类”。
查看功能分解，您可以认为函数指针属于类，就像方法一样。
所以要结束。就个人而言，我通常会选择（2）或（3）选项，因为它简洁，清晰，简洁，对“打字工作”的数量没有影响，如（4）。 Picking（1）可能会使用很少或没有目的的小文件使应用程序膨胀，这会让其他开发人员感到困惑。