Roo + GWT - 适合发展？

问题描述

我已经在GWT项目上工作了几个月，现在我决定尝试这个Spring Roo的事情。我注意到，从0到与Roo相同的结果可能需要很长时间。我的第一个想法是：这太好了！

但是，一旦你设置了几个持久化实体，Roo为GWT生成你的脚手架，并且你有一些非常基本的但是代码量很大。那又怎么样？你停止使用Roo并继续？ UI很不错，但是非常基础。

我不想亲手修改事情，因为我不想搞乱Roo一代。所以我只是删除所有的Roo的东西，我又回到了慢模式。

• 有没有人创建了一个相对复杂的应用程序有了Spring Roo + GWT吗？

我对Spring不太熟悉，所以它可能会变得丑陋（习惯了GWT + GXT + DataNucleus + Guice / Gin + Gilead公司）。你是否建议在这种情况下远离Roo？ b
$ b

从我的角度来看，Roo适合生成因为这是非常乏味的，但就是这样。

解决方案

从我的经验来看，Roo对于快速原型设计和概念证明。





保持数据模型与JPA / DAO层同步也是很有用的。





但的确，在服务级别和UI设计中更复杂的业务需求，您必须切换到普通的旧手动编码。




I've been working on GWT projects for a few months now and I decided to give a try to this Spring Roo thing. I noticed that to go from 0 to the same results as with Roo it can take very long. My first thought was: "this is great"!

But once you've setup a couple of persistent entities and Roo generates your scaffolding for GWT and you have some very basic layout but a huge amount of code. Then what? You stop using Roo and go on by hand? The UI is nice but is very basic.

I don't want to modify things by hand since I don't want to mess up Roo generation. So I just remove all Roo stuff and I fall to the "slow" mode again.

• Has anyone created a relatively complex application with Spring Roo + GWT?

• I'm not very familiar with Spring so it might get ugly (used to GWT + GXT + DataNucleus + Guice/Gin + Gilead). Do you recommend staying away from Roo in such a case?

From my point of view, Roo is good for generating the domain layer boilerplate since this is very tedious, but that's it.

解决方案

From my experience, Roo is very useful for quick prototyping and proof of concept.

It's also useful to maintain the data model in sync with JPA/DAO layer.

But indeed, for more complex business requirements at service level and UI design, you'll have to switch to plain old manual coding.

这篇关于Roo + GWT - 适合发展？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！