正在排列解决方案文件

本文关键字：文件 解决方案 排列 | 更新日期: 2023-09-27 18:21:25

我的C#.NET解决方案文件一团糟，我正试图找到一种方法来整理事情。

我试着把所有关闭的文件放在我为此目的创建的同一个文件夹中。例如，我将接口、抽象类及其所有继承的类放在同一个文件夹中。顺便说一句，当我这样做的时候，我需要写一个指向该文件夹的"using"语句，这样我就可以在其他文件中使用这些类（我想也是一团糟）。

  1. 有没有一种优雅的方法可以让事情变得更干净，而不是列出我觉得很困惑的文件列表
  2. 打开一个抽象类文件，并为从中派生的所有类添加嵌套类，这是一个好主意吗
  3. 有没有一种方法可以告诉解决方案在我创建的每个类之上自动设置文件夹"using"语句

正在排列解决方案文件

最好的方法是当您的解决方案文件系统结构反映您的程序体系结构而不是您的代码体系结构。

例如：如果你定义了一个抽象类，然后有了实现它的实体：如果它们是同一软件体系结构单元的一部分，就把它们放在同一个"篮子"（解决方案文件夹）中。

在这种情况下，通过查看解决方案树，可以从顶部视图（或多或少）看到您的体系结构是什么。

有不同的方法来加强对代码文件系统的架构愿景、理解和感觉。例如，如果您使用一些已知的框架，如NHibernate或（例如）ASP.NET MVC，则倾向于以技术所称的名称来调用这些东西，通过这种方式，熟悉技术的人可以很容易地在您的体系结构中找到自己。

例如，WPF强制您以某种方式在代码中定义事物，但您也需要以Model、ModelView、View的方式进行定义。。您将在seprate文件中直观地执行此操作。该技术要求您按照人们的想法定义文件系统。

顺便说一句，你要问的主题是众所周知的dilema/question，没有解决，因为代码只是字符序列，没有其他内容。

祝你好运。

听起来你已经到了真正需要把事情分解的地步，但你正在抵制这种做法，因为更多的文件似乎更复杂。这在一定程度上是正确的。但也有一点是，文件变得很大，无法管理，如果你试图创建嵌套类，你可能会在这里结束。

将代码保存在不同的命名空间中实际上是一件好事——这就是文件夹遇到的"问题"，并且必须在文件顶部添加using语句。名称间距允许您在逻辑上划分代码，甚至偶尔重用类名，而无需占用代码库的其他部分。

您使用的Visual Studio版本是什么？VisualStudio的一个鲜为人知的功能是，当您键入类名时，它可以自动创建using指令。这将消除一个痛点。

如果我站在你的立场上，我会开始寻找逻辑位置，将我的代码划分为不同的项目。你肯定也可以在这里做得过火，但这很常见：

  • 包含业务逻辑和业务对象的"核心"项目
  • 您构建的不同用户界面的UI项目，如网站或Windows窗体应用程序
  • 处理与数据库的所有交互的数据层项目。您的业务逻辑与数据层对话，而不是直接与数据库对话，这使得以后更容易对数据库设置进行更改

随着代码库的增长，像ReSharper这样的工具开始变得非常重要。我工作的代码库中有大约100万行代码和大约10个项目，如果没有ReSharper的文件导航功能，我就无法生存。它可以让你点击键盘快捷键，开始键入文件名，然后在找到匹配项时跳转到它。这有点像使用谷歌来查找信息，而不是试图为你遇到的每个有趣的链接添加书签。一旦我做出了这种心理转变，在代码库中导航就变得容易多了。

尝试在同一解决方案中使用多个项目来实现订单。为网络、实体、数据访问、设置、测试等分离项目

如果文件在同一个命名空间中，则不需要using语句。如果您将代码分解为多个项目，则需要使用using语句引用其他项目。

  1. 这取决于你。按逻辑把事情分开。在您认为必要的地方使用子文件夹
  2. 不确定
  3. 是的，但您需要创建一个模板。在上面搜索芭蕾舞裙

1）您的解决方案文件夹应该与您的命名空间结构相匹配。Visual Studio设置为以这种方式工作，并将自动创建匹配的命名空间。是的，这需要一个using来存放文件夹中的东西，但这就是它的用途。

所以，是的，将常见的东西组合在一个适当的名称空间下。

2） 是的，子类可能应该和它们的抽象基放在同一个命名空间/文件夹中，或者放在它的子文件夹中？如果是这样的话，我一般不会说，除非它们非常非常简单。不同的文件，相同的文件夹。

3） 我不知道。如果你在使用类名时右键单击它，你可以让Studio自动解析它，并添加一个使用（Ctrl+也这样做）

相关文章：