将Delgates放在.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) 可能会因为带有很少或没有用途的小文件而使您的应用程序变得臃肿，这会让其他开发人员感到困惑。