“魔法”有什么问题？ [英] What's wrong with "magic"?
问题描述
我想决定是否使用Rails或Django大师为我创建一个网络应用程序。我被推荐使用Django，因为它使用较少的魔术。从我的角度来看，Rails的魔法似乎是一件好事，因为它可以使我的承包商的开发变得更加简洁，从而减少了可支付的费用。我了解Django的优势可能会更好的细粒度控制，但是如何知道我是否需要这个控件呢？是否有魔法的固有问题？
嗯，考虑几个Rails魔术：当你写一个控制器类，其方法可以访问某些变量和某些其他类。但是，您正在查看的Ruby代码文件中的任何内容都不会定义和导入这些变量和类。 Rails在幕后做了大量工作，以确保他们自动进入。当您从控制器方法返回某些内容时，Rails确保将结果传递给适当的模板;你不必写任何代码来告诉它使用哪个模板，哪里可以找到它等等。
换句话说，就好像这些事情由魔术发生;您不必抬起手指，他们只是为您而生。
相比之下，当您编写Django视图时，您必须导入或定义任何您计划的内容要使用，您必须明确说明哪个模板要使用，以及模板应该能够访问的值。
Rails的开发人员认为这种魔法是一件好事，因为它使得快速获得某些工作变得更加容易，除非你想达成目标并开始重写事情，否则不会有很多细节。
Django的开发人员认为，这种魔法是一件坏事，因为真的不会节省很多时间（几个 import 声明在事情的宏伟计划中并不重要），并且具有隐藏真正发生的情况的效果，使得更难以解决如何重写东西，或者如果出现问题，更难调试。 >
这两个都当然是有效的一般来说，人们似乎自然地倾向于一个或另一个;那些喜欢围绕Rails或者框架尝试模仿它的那些魔术的人，那些没有聚集在Django上的人或试图模仿它的框架（而在更广泛的意义上说，这些立场就是Ruby和Python的定型观念）开发人员; Ruby开发人员倾向于喜欢做一些事情，Python开发人员倾向于喜欢以另一种方式做事情）。
从长远来看，它可能不会对于您所关心的因素而言，巨大的差异 - 可收费的时间 - 所以让您的开发人员选择他或她最舒服的方式，因为这更有可能为您获得有用的结果。
I'm trying to decide whether to use a Rails or a Django guru to create a web app for me. I've been recommended to use Django because it uses less "magic". From my perspective however, the "magic" of Rails seems like a good thing since it could make development more concise for my contractor resulting in fewer billable hours at my expense. I understand the advantage of Django might be greater fine-grained control but how will I know if I need this control? Is there an inherent problem with "magic"?
Well, consider a couple bits of Rails "magic": when you write a controller class, its methods have access to certain variables and certain other classes. But these variables and classes were neither defined nor imported by anything in the file of Ruby code you're looking at; Rails has done a lot of work behind the scenes to ensure they'll just be there automatically. And when you return something from a controller method, Rails makes sure the result is passed along to the appropriate template; you don't have to write any code to tell it which template to use, where to find it, etc., etc.
In other words, it's as if these things happen by "magic"; you don't have to lift a finger, they just happen for you.
By contrast, when you write a Django view, you have to import or define anything you plan to use, and you have to tell it, explicitly, which template to use and what values the template should be able to access.
Rails' developers are of the opinion that this sort of "magic" is a good thing because it makes it easier to quickly get something working, and doesn't bore you with lots of details unless you want to reach in and start overriding things.
Django's developers are of the opinion that this sort of "magic" is a bad thing because doesn't really save all that much time (a few import statements isn't a big deal in the grand scheme of things), and has the effect of hiding what's really going on, making it harder to work out how to override stuff, or harder to debug if something goes wrong.
Both of these are, of course, valid stances to take, and generally it seems that people just naturally gravitate to one or the other; those who like the "magic" congregate around Rails or frameworks which try to emulate it, those who don't congregate around Django or frameworks which try to emulate it (and, in a broader sense, these stances are somewhat stereotypical of Ruby and Python developers; Ruby developers tend to like doing things one way, Python developers tend to like doing things another way).
In the long run, it probably doesn't make a huge difference for the factor you say you're concerned with -- billable hours -- so let your developer choose whatever he or she is most comfortable with, since that's more likely to get useful results for you.
这篇关于“魔法”有什么问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
