Thoughts on Software by Andrew Davey
| | Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|
| 29 | 30 | 1 | 2 | 3 | 4 | 5 | | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | 13 | 14 | 15 | 16 | 17 | 18 | 19 | | 20 | 21 | 22 | 23 | 24 | 25 | 26 | | 27 | 28 | 29 | 30 | 31 | 1 | 2 | | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
Search
Navigation
Categories
Blogroll
|

Wednesday, October 17, 2007
Mobile Model Screencast
My latest screencast is online: Mobile Model in MVP web app
This screencast continues from the work I demonstrated in a previous screencast: http://channel9.msdn.com/Showpost.aspx?postid=344711
When implemented a Model-View-Presenter pattern client-side in JavaScript there is a need to get data from the server. Rather than make this divide explicit with HTTP request, etc, I have used the idea of a model object that moves between the client and server.
So the programmer simply writes the client and server pieces of functionality and lets my framework do the plumbing.
I use code generation and Script# to make writing a client-side web app much more seemless than the usual javascript/XML/JSON/web service madness.
I'm developing the ideas shown here in a project at the moment. If there is sufficient interest I may extract a framework to give to the community.
How do people feel about this approach to web development? What kinds of additions/modifications should be made?
p.s. I have a bit of a cold at the moment, so sorry for the croaky voice in the recording!
Wednesday, October 17, 2007 8:32:19 PM (GMT Standard Time, UTC+00:00)
.net | c# | mvp | programming | ria | screencast | tier_split | web

Sunday, September 30, 2007
Thoughts on client-server communication for the Model in MVP
I am thinking about my client-side MVP pattern and how best to communicate with the server. The current issue is how explicit to make the client/server divide. There are ways to make it feel like the Model is one consistent class, with tools doing all the marshalling to the server, invocation and return. This papering over of the "cracks" may however bite me in the ass at a later date. I reckon that adding the required flexibility to enable tweaking will just end up making the divide explicit again - rendering the exercise pointless.
So the alternative is to write the model with only client-side code. The server-side logic will then be in a service class somewhere. A benefit here is that the developer is free to choose the service style (SOAP, REST, etc).
I still want to avoid writing the client-side model proxy class that calls to the server. A tool is needed to take a service description and create a proxy class. In the context of a JavaScript model object, we need the proxy to be making XML HTTP requests.
I would like to use WCF to create the service. This is a good overview of getting WCF to talk JSON. If I enable meta-data transfer on the service, writing a tool to read this and create a proxy class should be simple.
Sunday, September 30, 2007 9:02:14 AM (GMT Standard Time, UTC+00:00)
.net | mvp | thinking | tier_split

Saturday, September 29, 2007