在.Net解决方案中，委托应该放在哪里？

Question

在.Net解决方案中，委托应该放在哪里？

6

我有一个C# .Net解决方案的集合，最初作为概念验证开始，并已发展到近15个不同的项目。我目前正在重写整个产品系列，并尽力保持最佳实践和未来可扩展性。

我已经进行了一些研究，但仍不清楚在多项目产品中保留委托的最佳位置，以尽量减少未来需要重构的可能性。

我认为普遍共识是将它们放在任何对用例有意义的地方，但总的来说，我感觉有一种最佳方式来结构化解决方案中的所有内容，以最小化问题，促进积极的模块化和便于维护。

在许多情况下，建议随所使用的地方一起传递，即在类文件上面的命名空间中声明，这在我的情况下将转换为带有强制使用事件的公共接口的公共库。我当前将委托放在自己的文件中，在“delegate”命名空间中。我是否犯了疏忽，或者是否过于复杂化了委托的使用情况 - 还是这符合当前的使用预期？

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

- Élie

5

如果项目很大，而且你想要SOLID类型的解耦，我建议将委托（delegates）与“接口”一样进行处理，即在独立的程序集中处理委托，使发布者/实现和订阅者/回调代码都与委托程序集（以及它们使用的任何类型）耦合，而不是直接耦合在一起。我必须承认，现在更常见的做法是看到没有显式委托类型的裸露的“Func”或“Action”（类似于泛型 IEnumerable 和 ILists<> 等的思想）。 - StuartLC

谢谢StuartLC！Func/Action/Predicate/Converter/Comparison对我来说是新的。感谢您让我注意到它们！ - Élie

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- atlaste · Accepted Answer

我认为普遍共识是你可以把它们放在任何有意义的使用情境中，但总体而言，我觉得在解决方案中结构化一切的最佳方式是为了最小化问题、促进积极的模块化和便于维护。

嗯，是的，在一般情况下，你可以随心所欲地把一切都放在任何地方。然而，当你在一个团队中工作时，问题就开始了。在一个团队中，其他人必须理解程序的结构才能有效地创建代码。这意味着需要一致性，这是最终目标。

因此，这不仅仅是凭直觉而定；在我工作过的所有公司中，我通常会先编写编码标准，并在各个方面积极执行它。在这个编码标准中，我通常会列举大量关于线程、静态使用、变量/类的位置等好/坏实践。

这段话的大意是：提供了两个链接，虽然前一个有点过时，但两个链接都不能完全回答问题。对于委托，将其放在自己的文件中并使用命名空间是合理的。共享接口的通用库是有意义的，因为接口是客户端和服务器之间的契约，是解耦软件的重要资产。

具体翻译如下：

我记得这个链接 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）那样增加打字工作量。选择（1）可能会使您的应用程序充斥着毫无意义的小文件，这会让其他开发人员感到困惑。