I think you're viewing the whole concept as a client-server app mechanism. Maybe you could do that in .Net by using an ActiveX client control, but you wouldn't get any business from me, since ActiveX cannot be used on my OS/browser.
JSF is an HTTP function at its root, and as such, you don't set up components and let them chat back and forth the way you would in client/server. Instead, the JSF
servlet gets an HTTP request, constructs objects, invokes the object methods, and the result are then converted into an HTTP response stream which is then transmitted back to the user's web browser. Once the final byte of the HTTP response stream has been transmitted, all of the server objects that are not either part of the server object set (application objects) or stored in the user's session are destroyed.
That has absolutely nothing to do with CRUD, however. I have a very nice little architecture for doing basically nothing
but CRUD built on JSF. It uses common
JEE design
patterns and ORM to manage the CRUD, and those parts of the system could care less what's managing the display part of the app. JSF manages the display and talks to the business layers, which in turn talks to the persistence layers and everything's neat and tidy. It's not all rammed into one file like an ASP, but it's a lot easier to maintain all those simple uniform little pieces-parts than it would be to wrestle with large irregular do-everthying files.
