0

Starting a new GWT application and wondering if I can get some advice from someones experience.

I have a need for a lot of server-side functionality through RPC services...but I am wondering where to draw the line.

I can make a service for every little call or I can make fewer services which handle more operations.

Let's say I have Customer, Vendor and Administration services. I could make 3 services or a service for each function in each category.

I noticed that much of the service implementation does not provide compile-time help and at times troublesome to get going, but it provides good modularity. When I have a larger service, I don't have the modularity as I described, but I don't have to the service creation issues and reduce the entries in my web.xml file.

Is there a resource issue with using a lot of services? What is the best practice to determine what level of granularity to use?

Bruce Chidester
  • 621
  • 1
  • 5
  • 16
  • Any comment WHY someone thinks this is a bad question? – Bruce Chidester May 09 '12 at 00:14
  • Because you're asking for advice; there is no perfect answer (everybody will disagree). 'Is there a resource issue with using a lot of services?' is a good answerable question. But the design pattern part of the question might be better for http://programmers.stackexchange.com. – Ishtar May 09 '12 at 10:08

3 Answers3

1

in my opinion, you should make a rpc service for "logical" things. in your example:

one for customer, another for vendors and a third one for admin

in that way, you keep several services grouped by meaning, and you will have a few lines to maintain in the web.xml file ( and this is a good news :-)

More seriously, rpc services are usually wrappers to call database stuff, so, you even could make a single 'MagicBlackBoxRpc' with a single web.xml entry and thousands of operations !

but making a separate rpc for admin operations, like you suggest, seems a good thing.

Overnuts
  • 783
  • 5
  • 17
  • This is what I would like to do....but starting to feel guilty breaking best-practices design rules. I love to use the is-a, has-a relationship but you need to be careful with generalizations. For example, a car is a physical object, a car is a metal-object, a car is a transportation object, etc. All are correct, however, you will pay dearly (sometimes) for the wrong decision. I do like your response. – Bruce Chidester May 09 '12 at 16:53
  • I may very well accept your response as confirmation of my own, and move forward. I will wait for more to chime in first. I am hoping that someone will say..."You had better do this, or that will happen", or "XYZ is the least painful path" – Bruce Chidester May 09 '12 at 16:58
1

Read general advice on "how big should a class be?", which is available in any decent software engineering book.

In my opinion:

One class = One Subject (ie. group of functions or behaviours that are related)

A class should not deal with more than one subject. For example:

Class PersonDao -> Subject: interface between the DB and Java code.

It WILL NOT: - cache Person instances - update fields automatically (for example, update the field 'lastModified') - find the database

Why?

Because for all these other things, there will be other classes doing it! Respectively: - a cache around the PersonDao is concerned with the efficient storage of information to avoid hitting the DB more often than necessary - the Service class which uses the DAO is responsible for modifying anything that needs to be modified automagically. - To find the database is responsibility of the DataSource (usually part of a framework like Spring) and your Dao should NOT be worried about that. It's not part of its subject.

TDD is the answer

The need for this kind of separation becomes really clear when you do TDD (Test-Driven Development). Try to do TDD on bad code where a single class does all sorts of things! You can't even get started with one unit test! So this is my final hint: use TDD and that will tell you how big a class should be.

Renato
  • 12,940
  • 3
  • 54
  • 85
  • I like your response a lot...however, your confirming one part of my conundrum. I am bound by training to make an object a single noun. My challenge is defining how big of a noun to define. If I define the class to granular..I end up with lots of services. You have helped me think about my question better..and appreciate your input. – Bruce Chidester May 09 '12 at 16:49
  • I thought of something which might make my response more clear. Objects can have a large hierarchical relationship....and the RPC call is effectively like calling somewhere in this relationship. My question is rooted at, do I create a "taller" hierarchy on the server-side, or shorter. I hope I described myself OK. – Bruce Chidester May 09 '12 at 17:06
  • Thank you for your comments. From my experience, you must never mix things that are part of different contexts together. This is because programs rapidly become complex as they grow, so you should keep each unit of your program as simple as possible, and at the same time try to keep dependencies to a minimum. Back to the PersonDao... if there is some other Object that you may only consider with relation to a person, such as a "Enrolment" Object in a student db, maybe it makes sense to make this Enrolment Object accessible only through a Person Object... so you won't have a Dao for every... – Renato May 09 '12 at 22:59
  • ... single Object... and the same concept applies everywhere. When you try to write unit tests and you find it difficult to write code to test an Object in isolation, though, that means you probably have too many responsibilities grouped in a class. Hope this makes sense. – Renato May 09 '12 at 23:04
  • But to be more specific about GWT services (or any type of service), I generally find that it makes sense to group functions together depending on the design of your UI. I find that many times, a screen needs to load lots of different things to display to the user, and it is a lot easier if you don't need to invoke lots of different services to get all the data that you need. So you may need to compromise a little bit and provide several functionalities within a single Service to improve client-code design and also efficiency. But this still follows the principle of one-subject, one-class. – Renato May 09 '12 at 23:09
  • I like that, "group functions together depending on the design of your UI". – Bruce Chidester May 10 '12 at 16:05
0

I think the thing to optimize for is that you can accomplish a result in one round trip to the server. I have an ad-hoc collection of methods on my service object, one for each situation the client finds itself in when it has to get something done. You do not want the client to RPC to the server several times in a row while the user is sitting there waiting.

REST makes things orthogonal, but orthogonality has a cost: there is a reason that the frequently used verbs in languages are irregular. In terms of maintaing clean orthogonal structure to your app, make sure your schema is well-designed. That is where each class should have semantics orthogonal to that of the other classes. When the semantics of each RPC call can be stated cleanly in the schema there will be no confusion as to what they mean, even if they aren't REST-fully ideal.

Daniel
  • 1,861
  • 1
  • 16
  • 24