So, what are reliability/scalability requirements? I suspect nothing outstanding ;) Anyway, problem with blocking RPC calls is your are hard capped on the amount of concurrent users. Caching does improve that. I really do not have numbers to tell what one can expect from this setup in "ideal" case. To improve scalability one needs to rework all the code dealing with RPC to use some kind of async patter, like events or Continuation Passing Style (CPS). I've had some success with CPS, but it surely complicates the code compared to plain request/reply. It laso has a wide impact on the system overall, spreading async callback all over the place. You can't have it encapsulated in some layer. It's a whole architecture/paradigm shi(f)t.
So, if you ever expect yourself in the need to transition to asyc calls, do consider messaging beforehand. It lets you have this model of work from the get go. And it does have a side benefit of being more scalable/reliable from the start. You don't have to use ajax in the browser. It will still work given your requests do not time out. In any case you won't be able to databind to your server domain model on the client. This are my thoughts on why I'd use messaging in a setup like yours, ie. web mvc backed up by some server. I'n my case I have a need to manage evergrowing in features integration with at least 2 external systems. I don't have any control on those. Add a requirement of web app at least not failing measerably when any or both are inaccessible. I'm still at crossroads if I'm ever going to make this transition (from web froms, sic!) with regards to my timelines... >From my experience when working with 3rd parties you tend to get data from them in some kind of DTOs anyways. On Wed, Jun 17, 2009 at 4:08 PM, Craig Neuwirt <[email protected]> wrote: > Thanks for all of your feedback. It's been very helpful. Currently, > there is no performance issue with respect to data access. I am a big fan > of databinding to domain model, but the client wants to remove all access to > the db in the DMZ. Messaging will certainly replace the workflow aspects of > the app so I was trying to minimize the types of communication from the app > layer. I agree messaging is not really optimal for data querying,but I so > don't look forward to having to define a bunch of data contracts to > represent the query results. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
