It is the 'I' in DI that I reflected on: Injection takes cpu cycles and on App Engine server cpu cycles are severely restricted by numerous quotas; the penalty for exceeding them cause cascading conditions of failure. If you aren't familiar with App Engine hosting and its quotas perhaps you should read up on it.
As for ROO not generating server side DI as part of its tooling in STS when used with GWT I will have to check that out for myself; I believe I had read that it generates a server side application context configuration file and if that is the case then I'd like to know why it would do that if DI wasn't employed on the server. If that is the case then DI would certainly cause heightened latency causing an increase in 500 errors on App Engine virtual server cold starts.
As for DI being a best practice (that you'd encourage *anyone* to follow) well that is your opinion that is not shared by everyone. I encourage a more conservative approach to any engineering problem - use the right set of tools at the right time.
As for Huh!?! That is something best saved for your friends on Facebook. This is a technical news group where such antics of conversation are not appreciated regardless of difference of opinion.
Jeff
On Sun, Oct 31, 2010 at 5:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
We've been prototyping with RequestFactory for months and haven't ever
On 30 oct, 23:15, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> Excellent! Thank you for the information. I still however have to wait until
> support for DAOs & embeded objects is implemented in the MVP framework (I am
> using Objectify for my ORM as well ass a DAO) before I can cut over.
>
> I am also concerned about the apparent reliance on Roo to generate the
> boilerplate code. It appears that Google is very much behind this combo.
used Roo (our backend is Morphia+MongoDB, not too far from Objectify)
AFAIK, Roo is only a dev tool to generate and maintain boilerplate
> It
> isn't that I have anything against Roo, DI or generated code for that matter
> but I would have preferred a leaner solution.
code. There's nothing related to Roo in the generated code (have a
look at the Expenses sample, the domain objects and all Scaffold*
classes are those generated by Roo).
RequestFactory goes against DRY as you have interfaces extending
EntityProxy on the client-side, and "whatever" on the server-side; but
it's lighter weight than e.g. GWT-RPC at runtime: lighter payload
going on the wire (in most cases, and particularly on "upload"), and
much much lighter and faster on the client-side as parsing the payload
is just a matter of JSON.parse()
Huh!?!
> Applications targeting App
> Engine already experience enough latency on start-up and I am afraid that DI
> will just make matters worse;
Could you explain to me how DI slows things down? It's merely about
moving the place where you "new" objects, I don't see where there'd be
overhead re. start-up time.
Noteworthy: Roo generates GWT apps that use GIN for DI on the client
side, but there's no DI at all on the server-side. And DI is
absolutely not a requirement; only a best practice (that I'd encourage
*anyone* to follow)
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
--
Jeff
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment