c# - 如何: Project Architecture for Unity3D or Spaghetti code?

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 3 年前。

Improve this question

20多年来，我一直在编写代码(多种编程语言)，并且始终使用设计模式和多种架构......层、职责分离、不同的类库、客户端/服务器等等...

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

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

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

我发现了一个article有一些信息，但仅此而已......没有别的了。

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

谢谢。

Answer 1

基础知识(传统脚本)

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

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

命名空间和项目结构

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

现代架构:实体组件系统

最近的发展催生了一种名为 Entity Component System 的架构。 (检查文档)。

An Entity Component System (ECS) architecture separates identity(entities), data (components), and behaviour (systems). Thearchitecture focuses on the data. Systems transform the data from aninput state to an output state by reading streams of component data,which are indexed by entities.

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