On Wed, Jan 26, 2011 at 7:52 AM, Ronald Woan <[email protected]> wrote:
> I am not entirely sure what the question is? Which model? From a meta > perspective, I think we have a client and server. The server provides a > Service Facade of a domain model from a SOA or distributed systems > perspective. The client consumes it as a Service (I have a little trouble > with resource). > > The client and server implementation architectures are independent and > bound only by the interface between them. You can certainly implement the > server using MVC but it's not a natural fit and I think just introduces more > complexity though I am sure someone will argue for it. > > I think Service is an important part of the name is because of the high > latency (relative), transactional characteristics that you may want to > design for rather than just providing CRUD operations. For example you > wouldn't want to implement 2-phase commit coordination at a client and would > rather have a single interface method called transfer money taking two > accounts and have a server make that an atomic transaction. In general I > think services modeling to be around interaction semantics and higher level > use cases than what I would think of as resource modeling. > > Ron > > I've started looking at the client and server as two separate applications, treating the server as just a service my client application is consuming. I think implement an MVC/P pattern in my JavaScript. I think the next greenfield web app I work on, I'd like to architect in this way. However, I'm also OK with the server generating HTML, but I dislike having the server output client behaviors. -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" 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/altnetseattle?hl=en.
