ember.js是否鼓励太多的控制器？ [英] Does ember.js encourage too many controllers?
问题描述
我正在努力了解构建ember.js应用程序的最佳实践。这张幻灯片从tomdale：
https://speakerdeck.com/u/tomdale/p/emberjs-more-than-meets-the-eye?slide=55
具有如何分配应用程序逻辑的简明描述。然而，在尝试遵循这些指导原则时，我发现了一些问题：
- 路由器增长太大。根据介绍，路由器响应视图中的事件，但是当有数十个视图时，这会导致很多代码。
- 有大量的控制器。在Rails应用程序中，CRUD操作通常驻留在同一个控制器中，但是对于ember应用程序，似乎应该有一个控制器来列出记录，一个用于查看记录，一个创建记录等。
它不觉得很干，因为我最终在控制器，视图和句柄模板之间的这么多文件，每个只有几行的代码。
我正在尝试确定问题是否正确地应用指南，或者这些准则是否适用于微不足道的应用程序。
$有没有人有任何建议 - 特别是如何管理路由器的增长？我认为说Ember鼓励太多的控制器就像说Javascript鼓励太多的功能。是的，你可以疯狂与任何一个的扩散。或者你可以做相反的事情，让它按照你的需要正常工作。一般来说，永远记住，您的应用程序应该与需要完全一样复杂，而不是这样。您不需要使用某种建筑或模式，只因为一些着名的编码人员使用它，甚至不是因为它似乎是Ember方式。即使是分离问题，MVC等普遍好事也是原则和原则。您应该尝试完全了解的模型，然后使用它们满足您的需求。我认为，正确的原因选择性地破坏规则和模式的能力远远超过了一个伟大的黑客的标志，而不是对编程神的教条的痴迷。这是一种工艺，而不是宗教。 （但是YMMV，也许有一个特殊的地狱圈子，为像我这样的编程人员保留，我打赌了。）
对于Ember，我倾向于使用控制器我的数据模型和/或围绕特定用户工作流，而不是围绕每个视图。然后使用路由/状态管理器作为您的视图之间的粘合，我通常在视图中使用事件管理器来处理每个视图内的浏览器事件，包括向路由器发送指令。所以，如果我有一个应用程序，说，客户和产品，我会有一个控制器的每个，就像我倾向于在Rails。这将导致每个控制器拥有比某些人喜欢拥有的更多功能和计算属性。这也意味着我不一定在另一个上下文中重用我的视图，因为它们与控制器连接牢固。是的，这是很差的担忧分离。但是，如果导致复杂性没有回报，那不是绝对好的。
同样关于控制器的主题，我认为人们特别倾向于不必要地增加控制器的主数据模型的子集。假设您有一个产品控制器，并且您想要将一个给定用户收集的产品存储在比较工具中。大多数人似乎为此创建了一个新的控制器，但将它们推送到产品控制器或客户控制器或客户型号中的额外数组或其他Enumerable是完全合法的。这样可以在更接近的范围内保持依赖相同功能和属性的对象。每个控制器中的内容对象是AFAIK，只是另一个Enumerable。它对控制器有一些特别的隐含参考，但不是魔术。没有任何功能原因我发现不使用额外的。他们的工作方式同样适用于绑定， #each 等。
同样，有些人只要LOOOVE打破他们的应用程序下降到一百万个文件，将它们嵌入到文件结构中的深度等等。如果这有助于您可视化基础逻辑，并为您的团队的其余部分做出明确的规定，您将获得更多的权力。对我来说，只是减少了一个只有1-3个工程团队的项目。人们也倾向于重现他们熟悉的其他MVC系统（如Rails）的基于文件的风格，其中文件是用于分离视图和其他逻辑对象的必要的显式结构。这成为一种信仰和深深根深蒂固的习惯。但是在Javascript MVC中，我发现它经常没有这样的用途，并且对于隐式设计是完全冗余的。我倾向于为我的整个Ember应用程序（与其他非库JS分离）使用一个单一的，精心组织的文件，具有大量的缩进和嵌套，这有助于我可视化层次结构。无论你做什么，文件化，在运行时都是一样的，只要你在正确的时间把它全部送到正确的地方。使用Ember和JS，文件结构是为了您的团队的需要，没有别的。相应校准。
（重要CAVEAT：如果您使用一百万个文件，最好使用预编译器将它们全部显示出来交付给用户，或者您将分担所有这些文件的延迟时间。）
（另一个重要CAVEAT：有一个大团队或快速的每日发布计划，如GitHub的，基于文件的逻辑分离使得版本控制比在同一个文件中进行大量合并更容易，而合并工具可能会让您感到困惑，同时，这是管理和监控您的人员流程以及仔细合并的问题，而不是由您的JS框架）
（最后重要的CAVEAT：再一次，技术要求和人类/程序需求之间的区别有时是模糊的，如果你打破了开发人员的大脑，你也有一个破碎的应用所以，做什么对于你需要处理的人员和流程来构建它。）
如前所述，YMMV。我不是一个编码的神，正如你可以从我的声望分数中得知的，所以你可能会自由地忽视我。但是，我坚持这样的想法，你应该只使用复杂程度，只需要尽可能多的文件结构，并且只能像许多更高级别的抽象（如路由，实际上对于有限目的的单页应用程序来说太过分了）作为服务你的需要而不再有。
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:
- The router is growing too large. According to the presentation the router "responds to events from views", but this results in a lot of code when there are dozens of views.
- There are a huge number of controllers. In a Rails application the CRUD actions typically reside in the same controller, however for ember apps it seems that there should be a one controller to list records, one to view a record, one to create a record, etc.
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?
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.)
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.
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.
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.)
(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.)
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屋！
