GWT ClientFactory: Isn't this just a big block / monolith?

Question

The GWT ClientFactory appears to be a new design pattern for GWT applications and although it is not officially part of the GWT API, it is encouraged by GWT and is found in countless GWT / MVP examples.

I like the concept of ClientFactory . But here is my concern: for really large applications that have many screens, display areas and complex architectures, one ClientFactory will become this massive monolith of a data structure with potential hundreds of getter methods on it.

So, I ask: is this normal? Why such a monolithic design is encouraged and acceptable for GWT, but not in other (general) applications. More importantly, is there a way to decompose the broadcast ClientFactory into a hierarchy of factory objects to help with maintainability of the code, dependencies / links, etc.?

If so, do you decompose ClientFactory into smaller factories, each of which is responsible for injecting another part of the application with the necessary presentations, presenters, etc.?

Answer 1

The idea of ClientFactory is simply a manual DI to make simple, straightforward wiring. Without knowing anything about the GIN or even GWT, these applications look mostly Java, allowing you to get an idea of ​​how to make the pieces work without having to learn. The specifics of the author are preferable to link the application.

As in the Java tutorial example, you start with public static void main(String[] args) , or maybe you create a fully manual servlet, you can use this to get this idea, and then move on to a better structured application. ClientFactory Utility is simplicity and transparency as a concept, and not because it is One True Way to create a large application.

Answer 2

As ben_w suggests:

Use Google Gin and build your application by creating some GinModules. Than you cn use @Inject at clients. This will help deal with Complexity. In fact, I would not start any project without dependency injection.