如何：Unity3D 或 Spaghetti 代码的项目架构？

Question

20多年来，我一直在编写代码（几种编程语言），总而言之，我一直在使用设计模式和几种架构……层、职责分离、不同的类库、客户端/服务器等。 ..

然而，在这个周末只是为了好玩和好奇，我安装了 Unity 3D 并试了一下。虽然我可以在 Visual Studio 中打开文件，但我不了解 unity 项目的默认文件结构。

我创建了嵌套文件夹以组织我的代码，但是当我尝试创建一个类时，出现了许多问题：

• 命名空间在哪里？为什么我需要自己写？它们应该是自动的并考虑到“文件夹”结构吗？
• 如何创建/重用/导入不同的项目类库？
• 如何管理nuget包？
• 以及我一生在编程中所做的一切......

我找到了一篇包含一些信息的文章，但仅此而已……没有别的。

我想知道是否有人可以为我指出关于这个主题的正确方向。

谢谢。

Answer 1

基础知识（传统脚本）

在 Unity 中，C# 被用作脚本语言，但受到许多限制并且旨在以某种模式使用。每个 Unity 脚本都源自 MonoBehaviour，正如您在文档中所读到的那样，它实现了特定的方法。此外，您不能使用 new 构造函数，而必须使用名为Instantiate的工厂方法。尽管如此，您可以使用其他类，只要它们正确包含并由任何 MonoBehaviour 脚本类使用即可。

虽然该主题存在意见分歧，但您可以找到有关 C# 脚本在 Unity 中结构不佳的意见[1]。

命名空间和项目结构

在 Unity 的早期版本中，普遍的共识是，当文件夹结构反映类型（例如图像和类别、每个类别的脚本、预制件、纹理等）时，较大的项目会更整洁，而当文件夹根据您的语义命名时，较小的项目会更整洁。项目（例如场景或特定功能）。命名空间是完全可能的，您可以在任何地方定义它们。尽管如此，正如您所想的，已经存在一个文件夹结构，并且命名空间不是 100% 模式，应该在大型项目中使用以避免冲突，正如文档所暗示的那样。

现代架构：实体组件系统

最近的发展导致了一种称为实体组件系统的架构（检查文档）。

实体组件系统 (ECS) 架构将身份（实体）、数据（组件）和行为（系统）分开。该架构侧重于数据。系统通过读取按实体索引的组件数据流将数据从输入状态转换为输出状态。

最近的开发改进了项目架构。不仅项目的可扩展性得到了改进，而且您如何回收代码或移植它也得到了改进。即便如此，您也必须遵循 Unity 模式并坚持接口。例如，Unity.Jobs 具有实现行为所需的接口 JobComponentSystem。最终，这一切都意味着坚持模式。现代项目应该坚持使用 ECS。