ember.js - ember.js 是否鼓励过多的 Controller ？

Question

我试图了解构建 ember.js 应用程序的最佳实践。这张来自 tomdale 的幻灯片:

https://speakerdeck.com/u/tomdale/p/emberjs-more-than-meets-the-eye?slide=55

有一个关于如何分配应用程序逻辑的简明描述。但是，在尝试遵循这些准则时，我发现了一些问题:

路由器变得太大了。根据介绍，路由器“响应来自 View 的事件”，但是当有几十个 View 时，这会导致大量代码。

有大量的 Controller 。在 Rails 应用程序中，CRUD 操作通常驻留在同一个 Controller 中，但是对于 ember 应用程序，似乎应该有一个 Controller 来列出记录、一个用于查看记录、一个用于创建记录等。

感觉不是很枯燥，因为我最终在 Controller 、 View 和 Handlebars 模板之间有很多文件，每个文件只有几行代码。

我试图确定问题是我错误地应用了准则，还是这些准则仅适用于琐碎的应用程序。

有没有人有任何建议 - 特别是关于如何管理路由器的增长？

Answer 1

我认为说 Ember 鼓励过多的 Controller 就像说 Javascript 鼓励过多的功能一样。是的，你可以为任何一种的扩散而发疯。或者你可以做相反的事情，让它完全按照你的需要工作。一般而言，请始终记住，您的应用程序应该与它需要的一样复杂，仅此而已。你不需要使用某种架构或模式，仅仅因为一些著名的编码人员使用了它，甚至因为它似乎是“Ember 方式”。即使像关注点分离、MVC 等“普遍的好东西”也是原则和模型，您应该尝试完全理解它们，然后在满足您需求的范围内使用它们。我认为，以正确的理由有选择地破坏规则和模式的能力比对编程之神教条的盲目忠诚更能说明一个伟大黑客的标志。这是一种手艺，而不是一种宗教。 (但是 YMMV。也许有一个特殊的 hell 圈是为像我这样的程序员保留的。我打赌。)

具体到 Ember，我倾向于在我的数据模型和/或特定用户工作流周围使用 Controller ，而不是在每个 View 周围。然后使用路由/状态管理器作为 View 之间的粘合剂，我通常在 View 上使用事件管理器来处理每个 View 内的浏览器事件，包括向路由器发送指令。因此，如果我有一个围绕客户和产品的应用程序，我将为每个应用程序提供一个 Controller ，就像我在 Rails 中所做的那样。这将导致每个 Controller 拥有比某些人喜欢在一个地方拥有更多的功能和计算属性。这也意味着我不一定能在另一个上下文中重用我的 View ，因为它们是硬连接到 Controller 的。是的，这是一个糟糕的关注点分离。但是，如果它导致没有返回的复杂性，那并不是绝对好的。

同样在 Controller 的主题上，我认为人们特别倾向于为主数据模型的子集不必要地增加 Controller 。假设您有一个产品 Controller ，并且您希望将给定用户正在收集的产品存储在比较工具中。大多数人似乎为此创建了一个新的 Controller ，但将它们推送到产品 Controller 或客户 Controller 内或客户模型上的附加数组或其他可枚举中是完全合法的。这使依赖相同功能和属性的对象保持在更近的范围内。 content每个 Controller 中的对象，AFAIK，只是另一个 Enumerable。它有一些对 Controller 的特殊隐式引用，但并不神奇。我没有发现不使用其他功能的原因。它们与绑定(bind)一样有效，使用 #each ， 等等。

类似地，有些人只是喜欢将他们的应用程序分解为一百万个文件，将它们嵌套在文件结构中 15 个深处，等等。如果这有助于您可视化底层逻辑，并让其余的人清楚你的团队。对我来说，它只会减慢我只有 1-3 人工程团队的项目的速度。人们还倾向于重现他们熟悉的其他 MVC 系统(如 Rails)的基于文件的风格，其中文件是分离 View 和其他逻辑对象的必要显式结构。这成为一种信仰和根深蒂固的习惯。但是在 Javascript MVC 中，我发现它通常没有这样的目的，并且对于隐式设计来说是严格冗余的。我倾向于为我的整个 Ember 应用程序使用一个精心组织的单个文件(将它与任何其他非库 JS 分开)，其中包含大量缩进和嵌套，这有助于我可视化层次结构。无论您做什么，在文件方面，运行时都是一样的，前提是您在正确的时间将其全部交付到正确的位置。使用 Ember 和 JS，文件结构是为了你的团队的需要，没有别的。相应地进行校准。

(重要警告:如果您确实使用了一百万个文件，则最好使用预编译器将它们一起显示以交付给用户，否则您将在单独交付所有这些文件时遭受巨大的延迟.)

(另一个重要的警告:对于大型团队或 rapid daily release schedule like GitHub's，基于文件的逻辑分离可以使版本控制比在同一文件中进行大量合并更容易，合并工具可能会混淆。再次，这是管理和监控您的人工流程以及仔细合并的问题，而不是您的 JS 框架强加的技术要求。)

(最后一个重要警告:再说一次，有时技术要求和人工/程序要求之间的区别是模糊的。如果你打断了开发人员的大脑，你的应用程序也往往会损坏。所以，做对人和流程有用的事情你必须处理它才能建成。)

正如我之前所说，YMMV。从我的声誉分数可以看出，我不是编码神，所以你可以随意无视我。但是我支持这样一种想法，即您应该使用尽可能多的复杂性、尽可能多的文件结构和尽可能多的高级抽象(例如路由，对于用途有限的单页应用程序实际上可能是过度的)您的需求;没有了。