ember.js 是否鼓励过多的控制器? [英] Does ember.js encourage too many controllers?
问题描述
我试图了解构建 ember.js 应用程序的最佳实践.这张来自 tomdale 的幻灯片:
I am trying to understand the best practices for structuring an ember.js application. This slide from tomdale:
https://speakerdeck.com/u/tomdale/p/emberjs-more-than-meets-the-eye?slide=55
简要描述了如何分配应用程序逻辑.但是，在尝试遵循这些准则时，我发现了一些问题:
has a concise description of how to apportion the application logic. However in trying to follow these guidelines I have finding some problems:
- 路由器变得太大了.根据介绍，路由器响应来自视图的事件"，但是当有几十个视图时，这会导致大量代码.
- 有大量的控制器.在 Rails 应用程序中，CRUD 操作通常驻留在同一个控制器中，但是对于 ember 应用程序，似乎应该有一个控制器来列出记录、一个控制器来查看记录、一个控制器来创建记录等.
感觉不是很枯燥，因为我最终在控制器、视图和车把模板之间有很多文件，每个模板只有几行代码.
It doesn't feel very DRY because I am ending up with so many files between the controllers, views and handlebars templates that each only have a couple of lines of code.
我正在尝试确定问题是我错误地应用了准则，还是这些准则仅适用于琐碎的应用程序.
I am trying to decide if the problem is that I am applying the guidelines incorrectly, or whether these guidelines only work for trivial applications.
有没有人有任何建议 - 特别是关于如何管理路由器的增长?
Does anyone have any advice - especially on how to manage the growth of the router?
推荐答案
我认为说 Ember 鼓励过多的控制器就像说 Javascript 鼓励过多的函数.是的，你可以为任何一种的扩散而发疯.或者你可以做相反的事情，让它完全按照你的需要工作.一般而言，请始终记住，您的应用程序应该与它需要的一样复杂，仅此而已.你不需要使用某种架构或模式，仅仅因为一些著名的编码人员使用了它，甚至因为它似乎是Ember 方式".即使像关注点分离、MVC 等普遍的好东西"也是原则和原则.您应该尝试完全理解这些模型，然后在满足您需求的范围内使用它们.我认为，以正确的理由有选择地破坏规则和模式的能力，比对编程之神教条的奴隶般的忠诚更能说明一个伟大的黑客的标志.这是一种手艺，而不是一种宗教.(但是 YMMV.也许像我这样的程序员有一个特殊的地狱圈.我打赌.)
I think that saying Ember encourages too many controllers is like saying Javascript encourages too many functions. Yeah, you can go crazy with proliferation of either. Or you can do the opposite, and have it work exactly as you need. In general, always remember that your app should be exactly as complex as it needs to be, and no more so. You don't need to use a certain architecture or pattern just because some famous coder guy used it, nor even because it seems to be 'the Ember way'. Even 'Universal Good Things' like Separation of Concerns, MVC, etc. are principles & models which you should try to understand fully then use to the extent that they serve your needs. I think that the ability to selectively break rules and patterns for the right reasons is far more telling a sign of a great hacker than slavish devotion to the dogma of the programming gods. This is a craft, not a religion. (But YMMV. Perhaps there's a special circle of hell reserved for coders like me. I'm betting against it.)
特别是 Ember，我倾向于在我的数据模型和/或特定用户工作流周围使用控制器，而不是在每个视图周围.然后使用路由/状态管理器作为视图之间的粘合剂，我通常在视图上使用事件管理器来处理每个视图内的浏览器事件，包括向路由器发送指令.因此，如果我有一个围绕客户和产品的应用程序，我将为每个应用程序提供一个控制器，就像我在 Rails 中所做的那样.这将导致每个控制器拥有比某些人喜欢在一个地方拥有的更多的功能和计算属性.这也意味着我不一定能在另一个上下文中重用我的视图，因为它们是硬连接到控制器的.是的，这是很差的关注点分离.但是，如果它导致没有回报的复杂性，那并不是绝对好的.
Specific to Ember, I tend to use Controllers around my data models and/or around a particular user workflow, rather than around each view. Then use Routing/State Managers as the glue between your views, and I generally use Event Managers on views to handle browser events within each view, including sending instructions to the router. So, if I have an app that revolves around, say, Customers and Products, I'll have a controller for each, just as I tend to do in Rails. This will result in each controller holding more functions and computed properties than some people like to have in one place. It also means that I can't necessarily reuse my views in another context, because they're hard-wired to the controller. And yes, this is poor Separation of Concerns. But that's not an absolute good if it causes complexity that has no payoff.
同样关于控制器的主题，我认为人们特别倾向于为主数据模型的子集不必要地增加控制器.假设您有一个产品控制器，并且您希望将给定用户正在收集的产品存储在比较工具中.大多数人似乎为此创建了一个新的控制器，但将它们推送到产品控制器或客户控制器内或客户模型上的附加数组或其他可枚举中是完全合法的.这使依赖相同功能和属性的对象保持在更近的范围内.每个控制器中的 content 对象，AFAIK，只是另一个 Enumerable.它有一些对 Controller 的特殊隐式引用，但并不神奇.我没有发现不使用其他功能的原因.它们与绑定一样有效，使用 #each 等.
Also on the subject of Controllers, I think folks particularly tend to proliferate controllers unnecessarily for subsets of your main data model. Say you've got a products controller, and you want to store the products that a given user is collecting in a comparison tool. Most people seem to create a new controller for this, but it's perfectly legit to push these into an additional array or other Enumerable inside of your Products controller or Customers controller, or on your Customer model. This keeps objects that rely on the same functions and properties within a closer scope. The content object in each controller is, AFAIK, just another Enumerable. It has a few special implicit references to the Controller, but isn't magic. There's no functional reason I've found not to use additional ones too. They work just as well with bindings, with #each, etc.
同样，有些人只是喜欢将他们的应用程序分解为一百万个文件，将它们嵌套在文件结构中的 15 个深处，等等.如果这有助于您可视化底层逻辑，并清楚地表明你团队的其他成员.对我来说，它只会减慢我只有 1-3 人工程团队的项目的速度.人们还倾向于重现他们熟悉的其他 MVC 系统(如 Rails)的基于文件的风格，其中文件是分离视图和其他逻辑对象的必要显式结构.这成为一种信仰和根深蒂固的习惯.但是在 Javascript MVC 中，我发现它通常没有这样的目的，并且对于隐式设计来说是完全多余的.我倾向于为我的整个 Ember 应用程序使用一个单独的、精心组织的文件(将它与任何其他非库 JS 分开)，其中有很多缩进和嵌套，这有助于我可视化层次结构.无论您做什么，在文件方面，运行时都是一样的，前提是您在正确的时间将其全部交付到正确的位置.使用 Ember 和 JS，文件结构是为了你的团队的需要，没有别的.相应地进行校准.
Similarly, some people just LOOOVE to break their app down into a million files, nest them 15 deep in the file structure, etc. More power to you, if that helps you to visualize the underlying logic, and make it clear to the rest of your team. For me, it just slows me down on projects with only a 1-3 person engineering team. Folks also tend to reproduce the file-based style of other MVC systems they're familiar with (like Rails), where files are the necessary explicit structure for separating views and other logic objects. This becomes an article of faith and a deeply ingrained habit. But in Javascript MVC, I have found that it often serves no such purpose and is strictly redundant to the implicit design. I tend to use a single, carefully organized file for my entire Ember app (separating it from any other non-library JS), with lots of indentation and nesting where that helps me to visualize the hierarchy. Whatever you do, file-wise, it's all the same at runtime, provided that you deliver it all to the right place at the right time. With Ember and JS, file structure is for the needs of your team, and nothing else. Calibrate accordingly.
(重要警告:如果您确实使用一百万个文件，您最好使用预编译器将它们一起显示以交付给用户，否则您将单独交付所有这些文件会造成巨大的延迟.)
(IMPORTANT CAVEAT: if you do use a million files, you'd better be using a pre-compiler to manifest them all together for delivery to the user, or you're going to take a huge latency hit on delivering all those files separately.)
(另一个重要警告:有一个大团队或 快速的每日发布时间表，例如GitHub 的，基于文件的逻辑分离可以使版本控制比在同一文件中进行大量合并更容易，因为合并工具可能会混淆.同样，这是管理和监控人工流程的问题, 并小心地进行合并，而不是您的 JS 框架强加的技术要求.)
(ANOTHER IMPORTANT CAVEAT: with a large team or a rapid daily release schedule like GitHub's, file-based separation of your logic can make version-control easier than doing lots of merges into the same file, where your merge tool may get confused. Again, this is an issue of managing and monitoring your human processes, and doing merges carefully, rather than a technical requirement imposed by your JS framework.)
(最后一个重要警告:再说一次，有时技术要求和人工/程序要求之间的区别是模糊的.如果您打断了开发人员的大脑，那么您的应用程序也往往会损坏.所以，做对在构建它时您必须处理的人员和流程.)
(LAST IMPORTANT CAVEAT: Then again, sometimes the difference between a technical requirement and a human/procedural requirement is fuzzy. If you break your developer's brain, you also tend to have a broken app. So, do what works for the people and processes you have to deal with in getting it built.)
正如我之前所说，YMMV.从我的声誉分数可以看出，我不是编码神，所以你可以随意无视我.但是我支持这样一种想法，即您应该只使用尽可能多的复杂性、尽可能多的文件结构和尽可能多的更高级别的抽象(例如路由，这对于用途有限的单页应用程序实际上可能有点矫枉过正)您的需求;没有更多.
As I said before, YMMV. I'm not a coder God, as you can tell from my reputation score, so you may feel free to disregard me. But I stand behind the idea that you should use only as much complexity, only as much file-structure, and only as many higher-level abstractions (like routing, which may actually be overkill for limited-purpose single-page apps) as serves your needs; and no more.
这篇关于ember.js 是否鼓励过多的控制器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
