21
Grails（现在）值得吗？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 12个月前关闭。 改善这个问题 我知道这是重复的，但是，自从一年多前提出这个问题以来，Grails世界已经有了长足发展，Eclipse中的IDE支持也是如此，所以请不要盲目关闭它。 我以为答案是肯定的，并且已经开始使用Grails 1.2.0进行新项目，并且对STS Eclipse Integration的Groovy / Grails情有独钟。 我认为在经过一年的Grails演变之后，这个问题肯定是混杂的，值得重新讨论这个问题。 因此，作为一名经验丰富的Java Web开发人员，我有以下问题，并且很欣赏我的假设受到挑战： Grails现在值得与Ruby对抗还是自己动手？ 它克服了越野车的起步吗？ 它真的赋予快速发展利益吗？ （我承认我现在正在努力地进行广泛的基准配置，以使我的定制应用程序不是面向列表和页面的） 它可用于现实世界的生产应用程序吗？ （感觉很重） Eclipse插件是否比以前更好并且适合特定目的？（我认为还没有） 谢谢 编辑： 我正在学习中，我对使用框架有很多重要的了解-而不是框架本身。我添加这些内容是因为我认为它们应该作为考虑因素，并基于我的经验和观点，并且可能会帮助试图决定是否放牧的人。我可能还显示出我缺乏该框架的经验，因此，这些都不是一成不变的批评。我是一位经验丰富的开发人员，这是我所发现的： 调试真的很难。实际上，这几乎是不可能的，尤其是对于框架的初学者而言，这是您最需要可信赖的调试器朋友的时候。我花了更多的时间来跟踪代码中某些部分的语法错误问题，这涉及到引用导致堆栈中某些地方出现静默故障的域字段。 坦率地说，日志记录很糟糕。您有两种模式，“无用”和“大量无用的东西”。单个页面请求后，我的调试日志为128Mb，其中不包含有关我的错误的信息。我认为整个日志记录问题都需要在框架中重新考虑。 STS Eclipse IDE具有边际价值。除了语法提示以外，它没有太多用处。您无法调试代码，因此它是出色的编辑器。代码提示是不完整的，据我所知，根本没有GSP支持。这也是我桌面上最慢的Eclipse插件-大约需要2分钟才能启动。令人震惊的缓慢。我已经恢复到文本编辑器（您会注意到所有在线教程视频也都这样做）和一些自定义语法提示。 我对性能有一些严重的担忧。现在说还为时过早，但是由于休眠，我已经发现自己正在调整数据库。也许这是意料之中的，但是我真的必须保持我的域模型简单，以使约定产生性能查询。 最后一点，关于逻辑域模型和物理数据库模型应该相同的约定不是明智的默认选择，在现实世界中不可能如此。我知道您可以将两者分开，但这会造成一定程度的复杂性，我认为如果扩展约定，可以避免。没有足够的文档来说明合成以及在实际操作中需要做什么。