我正在try 决定是使用Rails还是Django Guru为我创建一个Web应用程序.我被推荐使用Django，因为它使用的"魔法"较少.然而，从我的Angular 来看，Rails的"魔力"似乎是一件好事，因为它可以使我的承包商的开发更加简洁，从而减少以我为代价的计费小时数.我知道Django的优势可能是更好的细粒度控制，但是我怎么知道我是否需要这个控制呢？"魔法"有没有固有的问题？
我正在try 决定是使用Rails还是Django Guru为我创建一个Web应用程序.我被推荐使用Django，因为它使用的"魔法"较少.然而，从我的Angular 来看，Rails的"魔力"似乎是一件好事，因为它可以使我的承包商的开发更加简洁，从而减少以我为代价的计费小时数.我知道Django的优势可能是更好的细粒度控制，但是我怎么知道我是否需要这个控制呢？"魔法"有没有固有的问题？
考虑一下Rails的一些"魔力":当您编写控制器类时，它的方法可以访问某些变量和某些其他类.但是这些变量和类既不是由您正在查看的Ruby代码文件中的任何内容定义的，也不是由其导入的；Rails在幕后做了大量工作，以确保它们会自动出现在那里.当您从控制器方法返回某些内容时，Rails会确保将结果传递给适当的模板；您不必编写任何代码来告诉它使用哪个模板、在哪里查找等等.
换句话说，这些事情好像是通过"魔法"发生的；你不需要动动手指，它们就会为你发生.
相反，当您编写Django视图时，您必须导入或定义您计划使用的任何内容，并且必须显式地告诉它要使用哪个模板以及模板应该能够访问哪些值.
Rails的开发人员认为这种"魔术"是一件好事，因为它可以更容易地让一些东西快速工作，而且不会让您厌烦太多细节，除非您想要进入并开始覆盖一些东西.
Django的开发人员认为这种"魔术"是一件坏事，因为它并不能真正节省很多时间(从总体上看，import条语句并不是什么大事)，其效果是隐藏了实际发生的事情，使如何重写变得更加困难，或者在出现问题时更难进行调试.
当然，这两种立场都是正确的，一般来说，人们似乎只是自然而然地被其中一种吸引；那些喜欢"魔法"的人聚集在试图模仿它的轨道或框架周围，那些没有聚集在Django或试图模仿它的框架周围的人(从更广泛的意义上说，这些立场在某种程度上是Ruby和Python开发人员的刻板印象；Ruby开发人员倾向于以一种方式做事，Python开发人员倾向于以另一种方式做事).
从长远来看，这可能不会对你所关心的因素——计费小时数——产生很大影响，所以让你的开发者 Select 他或她最喜欢的，因为这更有可能在you分钟内得到有用的结果.