什么是文档完整、稳定、安全和可伸缩的Web应用程序框架？

Question

我们正在为我们的公司构建一个XML，它将提供RESTful、JSON和其他可能的内容类型。

我的小组正在寻找一个(按优先次序排列)的框架：

1. 有良好记录的
   • 最好有好的教程，繁荣的社区和知识库。

​

1. 遵循rational设计模式
   • 大多数情况下，我们想要框架中的一致性。根据您要调用的方法调用的命名约定不会更改。

​

1. 安全
   • 集中于迫使开发人员对GET、POST、PUT和DELETE变量执行某种形式的验证。

​

1. 稳定
   • 这部分是成熟的，因为框架没有太频繁的变化。
   • 另一部分是一个有详细记录的错误列表，它并不大得吓人。

​

1. 面向可扩展/性能的
   • 我们拥有超过50K的用户，他们在世界各地都需要大量的高可用性。如果我们的应用程序坏了，人们家里就没有互联网了。所以这是一个非常关键的环境。
   • 理想情况下，我们可以在10台服务器上发布相同的代码库，然后继续添加负载平衡器。我们不想定义哪个服务器在哪种方法上.

​

1. 与Linux/MySQL环境很好地集成
   • 我们没有一台MS服务器。我们不会改变的。抱歉，.Net粉丝:-D

​

我意识到这是个模糊的目标。不会有任何一个框架来满足所有这些需求，事实上，可能会有许多以不同的方式、形状和形式满足它们。

这是与语言无关的。我们已经有了PHP方面的经验，但我们也有一些开发人员从未编写过web应用程序，因此学习Python或Ruby或Java是可以接受的。

Answer 1

我将在这里讨论一下，建议Rubywith辛纳特拉.

为什么？

1. 西纳屈不是“有充分记录的”，而是“有记录的很好”。考虑到它比其他框架简单得多，所以不需要太多的文档，而且由于它是作为with服务器构建在Rack上的，所以它与其他框架共享一些共同的文档。但你需要知道的是在网站上，它写得很好，没有错误，我已经找到(IE，这都是最新的)。 您需要知道的大部分内容都在辛纳屈书、自述和常见问题中。尽管这本书的工作还在进行中，但它的内容非常准确和有用。如果你还在问问题，去IRC聊天室freenode.net#sinatra吧。
2. Sinatra能够在基于功能/路由的逻辑方法中使用，或者重写Sinatra::Application对象。您可以使用这两种方法，将逻辑和方法拆分为不同的文件，或者将其保存在一个文件中。一切都看你的了。
3. 西纳屈本身是安全的。您必须验证用户发送的所有变量，因为除了解析它们并将它们传递给您之外，Sinatra并不关心它的有效性。因此，要么执行变量的有效性，要么后悔。;-)
4. 在过去的四个月里，辛纳屈并没有发生任何变化，但是它确实有一些维护和小的更新。此外，我还没有发现bug列表很大或很有威胁。它几乎拥有我所需要的所有东西来构建我的应用程序。
5. 辛纳屈不需要部署乘客，但可以很容易地定制快速。如果您使用企业Ruby和瘦的之类的东西，您可以代理到Nginix或LightHTTPd。如果您使用两个服务器，您可以使一个服务器成为主服务器(使用代理和多个线程)，而第二个服务器可以使数据库服务器(使用MySQL和多个线程)并释放它们。这样，任务就会分散在服务器上。它会给你比我想的乘客更多的控制权。(更不用说更好的表现了。) 我发现与Rack、Mongrel或Thin运行线程相比，乘客(在Dreamhost上)的性能相对较差。也就是说，一旦加载了应用程序，即使在这种环境中，应用程序也是响应性的。如果我要预测它，您将不会在扩展应用程序方面遇到问题，因为您只需重新部署代码并重新启动线程--没有什么是不能放到Capistrano中的。
6. Linux上的Ruby非常快速，实现起来也不成问题。使用Ruby的MySQL非常容易，并且有几个非常好的ORM包可供使用，比如ActiveRecord和续集。辛纳屈不会让你选择你讨厌的人。

除了回答你的问题外，我还有几个理由。

1. 辛纳屈有一个简单的学习曲线，而且很容易学会。我遇到的最大问题是把它放到我的Dreamhost服务器上，因为Rack是一个较旧的版本，但是在Rack的一个流行版本中，这个问题消失了。如果可以的话，我会用ActiveRecord重写我在辛纳屈的最新Rails项目，以便让自己更容易维护；已经在它上花费了太多的精力。 由于它的易用性和易学性，我发现自己在没有代码生成器的Sinatra中比在Rails中拥有所有代码生成器更有效率。这是在说些什么。
2. Sinatra支持Rack中间件，因此在使用它时非常灵活。
3. 如果我要在IRC上平均考虑Sinatra社区的帮助，我会说他们比普通Rails用户更了解这个框架--只是粗略的比较。原因是Rails对新手和没有业务编程的人来说更容易访问。
4. Sinatra将支持Ruby1.9。我仍然不完全确定是否有多少支持1.9目前在西纳屈，但我知道他们最初是等待Rack。截至4月25日这不再是一个问题，所以想必辛纳屈已经为1.9做好了准备；我知道2009年年中1.9的支持正在酝酿之中，但我不知道这会持续多久。 假设您可以使用Ruby1.9(版本0.9.2已经支持Rack 1.0，以及Rack代码中的代理1.9 )使用Sinatra，那么在支持1.9的公共1.0之前，您在Ruby端的性能将非常出色。即使您做不到，Enterprise也会帮助提高速度。

Answer 2

Django和Rails都非常接近于您的大多数标准，但我认为Django的文档比Rails的文档要好得多；Django的文档简直太棒了(我在这里不是双曲线)。

不过，我不知道Django的可伸缩性。我很清楚Rails的规模(在某种程度上)，但我不知道Django是否也是如此。(我不是说它不能；我只是说我真的不知道，因为我从未使用Django编写过大型应用程序。)

Django也有一个小马，如果你也暗地里想要的话。

Answer 3

井。可伸缩性并不容易获得。对于类似Google的响应时间，您需要类似于MapReduce的东西。好的。别自欺欺人了，超级扩展对初学者来说是没有意义的。

至于所有其他要点，海滨显然是最好的。至于安全性，请查看seaside.st，以了解为什么它本身比我所知道的所有其他框架(包括Rails和Seam )都更安全。海滨被合理地记录下来了，但是也观察海边的内部结构是如此的简单和方便，以至于社区几乎没有一个问题可以回答，通常情况下都是这样。海边已经稳定了很多年了，所以我想你会同意的。

至于面向性能的:运行商业海滨，玻璃杯，您将获得惊人的性能相比，灯式的设置，因为更快的数据库解决方案是集成的，以及框架，以内存换取速度，并获得很大的速度。

海滨是如此良好的架构，以至于许多人发现编写海滨应用程序比桌面应用程序更容易。试试吧，你会喜欢的。

PS:说句公道话，海边不是RESTful。