+972 52-548-6969
Taking advantage on the Data Transfer Tier
When talking about RIA applications, we usually have the following physical architecture:
That is, we have the application actually running on the client’s machine, we access the host server in order to perform operations that cannot be made locally and we save to some persistent storage, usually an RDBMS.
The great advantage that in a RIA application, we have a real platform at the client side, and not the hack that is HTML + JavaScript. That make it a much more pleasant experience to actually work with them. However, we then encounter a very interesting choice. Where are we going to put the weight?
We have two choices, server side and client side. On the server side, we would need to develop a real service layer. This is usually called if the RIA app is making use of services that will also be consumed elsewhere. It is an old, traditional, approach. It is also more costly than the alternative, assuming that we need the server side only to support the application itself, which is quite common.
In many cases, the application itself is the only reason for development, and in that case, spending time in the server side is probably a waste of our time for a lot of tasks. It is easier and cheaper to perform tasks completely on the client. And at that point, the server side functionality is limited to “let us just expose the data the application needed” . It is no longer a real independent piece, it has became merely a data transfer tier, with no additional responsibilities.
Note: you still may want to keep some minor validation logic on the server side, but that is about the extent of server side functionality in this case. Well, that and authorization :-)
RIA Services are supposed to make building that part in RIA applications as simple as possible, making the data transfer side (which we are usually almost totally unconcerned with) as simple and idiot proof as possible.
This is why this post it titled taking advantage of. If you are aware that your server side functionality isn’t important, you can deal with it in as brutal a manner as possible, because that is not where you want to spend your time. You want to spend you time actually doing something useful, and that is probably going to happen all on the client side.
Comments
A classic example of this is the client server desktop app, with winforms connecting to a SQL database via storedprocs secured by SQL access rights. Good times...
Unless I'm making some one-off tool, I'm rarely making an application where the server side is not important (where rules beyond data-typing need to be enforced on the server).
Take advice from the MMO game developers: "Never trust the client".
RIA is great, now you can have a real .Net business object in your web app and fully enforce the rules there with some nice UI interactivity to boot.
However I would enforce the same rules on the server, maybe your client is not in a hostile environment, but why early optimize, remove rules checks on the server only if necessary.
We are shooting for a CSLA like "mobile object" approach where BO class source code is shared between the Silverlight client and full .Net server. The objects simply move from one tier to another before committing to the DB. I believe the Silverlight RIA framework does this too.
You're making a ton of sense to me.
We're talking about apps that control both sides of the wire, that secure access to the server so only authenticated clients get through, and that can accomplish most of what they need from the server by persisting a ChangeSet (aka, saving a bunch of new and changed entities in a transaction).
None of this precludes server-side authentication, authorization, and validation of every action. You're talking belt and suspenders in most cases (the "suspenders" being your "complete waste of time").
But some folks are really worried about keeping their pants up and customer cost be damned. For them the frameworks in this space make server-side replay easy to manage because they foster a single, dual-environment code-base that can execute both on the client (for responsiveness) and on the server (for paranoia).
They also faciliate server-only services where you need them; not their forte but more than sufficient when ChangeSet Persistence is carrying most of the load.
RIA Services, CSLA. .and DevForce all share this perspective. Check them out.
Funny enough, that 'hack' is arguably the most successful GUI technology to date.
Ayende
Isn't this assuming CRUD, lack of long running workflow (saga's), messaging etc?
Simon,
Yes, it is.
There is a wide variety of applications where this is actually what you want.
Think forms over data.
Comment preview