在.net解决方案中何处放置委托
本文关键字：何处放 net 解决方案 | 更新日期: 2023-09-27 17:51:25
我有一个c# . net解决方案集合，从一个概念验证开始，到现在已经发展到近15个不同的项目。我目前正在重写整个产品系列，并试图尽我所能，以面向未来的组织方式保持最佳实践。
我做了一些研究，但我仍然不清楚在多项目产品中保持委托的最佳位置，以尽量减少将来需要重构的可能性。
我认为一般的共识是您将它们放置在对用例有意义的任何地方，但一般来说，我觉得有一种最好的方法来构建解决方案中的所有内容，以最大限度地减少问题，促进积极的模块化，并简化维护。
在许多情况下，建议它们随使用地点一起旅行;大概是在类文件上方的名称空间中声明的，在我的例子中，它将转换为具有强制执行事件的公共接口的公共库。我目前有委托在他们自己的文件，在一个"委托"命名空间。这样做是否存在疏忽，或者我是否使委托的用例过于复杂——或者这是否符合当前的使用期望?
我做了典型的搜索，但没有找到任何可信或实质性的东西;然而，这可能是关键字选择不当的结果。
我认为一般的共识是你把它们放在任何地方这对用例来说是有意义的，但总的来说，我觉得有一个在解决方案中构建所有内容以最小化问题的最佳方式，促进正向模块化，便于维护。
嗯，是的，在一般情况下，你可以把你喜欢的东西放在任何地方。然而，当你在团队中工作时，问题就开始了。在团队中，其他人必须理解程序的结构才能有效地创建代码。这意味着一致性，这是最终目标。
所以，这不仅仅是直觉的问题;在我工作过的所有公司中，我都是从编写编码标准开始的，并积极地在所有地方执行它。在这个编码标准中，我通常会添加大量的好/坏实践，包括线程、静态使用、变量/类的放置等。
irc这个链接http://se.inf.ethz.ch/old/teaching/ss2007/251-0290-00/project/CSharpCodingStandards.pdf和https://msdn.microsoft.com/en-us/library/ff926074.aspx会给你一个良好的开端，尽管前者有点过时，两者都不能真正回答你的问题。然而，从长远来看，它可能会帮助你实现你想要实现的目标。
具有接口的公共库是有意义的。接口本质上是"客户端"answers"服务器"之间的契约，它是解耦一个软件的重要资产。 在这一点上，您必须意识到"接口"部分是一个功能分解，而不是一个技术分解。换句话说:你需要一个"接口"库的事实是一个契约的问题，而不是技术构造的问题。因此，我不明白为什么你会把类放在"类"文件夹中，为什么你会把委托放在"委托"文件夹中。简而言之，"委托"文件夹对我来说没有任何意义。把东西放到该放的地方去。 在这一点上，你需要做一个决定。(1)你可以把一个委托放在一个单一的文件，(2)你可以把一个委托在类文件中使用它(我通常使用委托为单一目的)，(3)你可以做这两个取决于单一/多用途和(4)你可以把单一用途的委托嵌套在类。这基本上意味着你把一个委托当作一个函数指针描述，而不把它看作一个真正的"类"。[…我现在有代表在场他们自己的文件，在一个"委托"命名空间。我是不是疏忽了或者我是否过度复杂化了用例委托——或者这是否符合当前的使用期望?
查看函数分解，你可以认为函数指针属于类，就像方法一样。
总结一下。就我个人而言，我通常选择选项(2)或(3)，因为它简短、清晰、简洁，而且不会像(4)那样对"打字工作"的数量产生影响。选择(1)可能会使您的应用程序充斥着几乎没有目的的小文件，这将使其他开发人员感到困惑。