我计划为我的投资组合创建一个小项目并在其中使用 MVP 模式。我之前从未使用过任何建筑模式。问题是在 Unity 中如何组织文件夹和脚本的层次结构。是否有必要对 Model、View 和 Presenter 文件夹进行严格的区分？而且脚本名里需要加上后缀Model、View、Presenter吗？提前感谢大家。
RError.com
我计划为我的投资组合创建一个小项目并在其中使用 MVP 模式。我之前从未使用过任何建筑模式。问题是在 Unity 中如何组织文件夹和脚本的层次结构。是否有必要对 Model、View 和 Presenter 文件夹进行严格的区分？而且脚本名里需要加上后缀Model、View、Presenter吗？提前感谢大家。
MVC…………MVP没关系MVVM！Model，它在非洲Model，View在火星View，这些都是独立存在的实体类别，而不仅仅存在于它们相互作用的模式框架内。FooModel如果两者同时拥有FooView，那么将它们统一起来的实体就是业务逻辑，它不需要规范和指定。如果您将某物称为
...Controller或...Handeler，那么在 100 种情况下，99 种情况都会被用作寄生名称，这在因果报应中已经是 -100^2 了。在这 99 种情况下，程序员自己并不理解该类到底承担什么责任，也无法赋予它一个能够体现这种责任的名字，你好Single Responsibility。背景永远很重要；同一个名称在不同情况下可以是具体的，也可以是模糊的。View？哪个View？一些UnitSkin，UnitBar和UnitLayout，这就是全部View，但一个负责带有动画的模型，第二个负责UI形式HP和MP头部上方，第三个负责UI屏幕边缘的图标，名称和其他一些信息。Skin这些词语Bar本身Layout说明了可视化，而添加View会使黄油变成黄油，这是一个平庸的套话。...View在只有一个上下文且严格无歧义的情况下添加。例如InventoryItem和InventoryItemView。游戏场景中有各种各样的治疗、强化道具、弹药筒，这些都是我们抽象概念的继承者。CollectableItem过程UnitCollector和包含。所有的继承者都是不同数据的载体，但它们的视觉逻辑是相同的，这是正常状态和选择的动画/声音，并且只能有一个类，或者一些使用它们自己的，但它们再次从主要类继承而来，如偏差。CollectableInventoryItemInventoryItemCollectableItemCollectableItemView...Model常加的，也可以...Data，意思是一样的，只有数据模型，没有业务逻辑。但同样，这不是必要的；可以有仅暗示数据的描述性名称。例如，您有一个经典的街机游戏，在游戏结束时，您会看到：时间、收集的硬币数量、杀死的敌人数量，这些信息都存储在structGameRecord或中SessionRecord，它甚至有自己的View，并且名称中不需要Model或。Data如果数据是独立且自给自足的，那么Model名称中不需要任何内容，类型struct本身就C#表明它是数据。即使在上述模板中，也可能存在具有不同名称的模型、处理程序和可视化，例如产品/仓库/商店。无论何种分类，编目都应该清晰一致，只要它不是一个会让你摔断腿而一无所获的垃圾桶即可。
Model如果对象由大量数据模型组成（如在ECS架构中）或者有很多数据模型（例如抽象+几个继承者），则文件夹是可以理解的View，它更容易导航，但是如果您只有 2,3,5......类，那么为什么需要 2-3 个文件夹和 1-2 个文件？如果您总是将一些单元测试放在单独的文件夹中Test，即使它只是一个看起来不错的文件，但在其他情况下它就是某种垃圾。编目的本质在于方便列出文件：如果文件很多，分类更方便；如果数量少的话，没有比较方便。