Just to make sure all readers can understand: MVC is indeed an appropriate pattern, and a nice example of Separation of Concerns as well. The Model is supposed to take care of the data access (including data business rules), the View of the data presentation (typically on a user interface), and the Controller adds application logic, translating user input into Model or View changes.
The original MVC pattern also describes particular communication channels between these three parts. Users interact with views. Controllers observe views and act upon user input, perhaps by initiating Model changes. Views again observe models for changes, to update their presentation. It is not that easy to work with observers in web applications, so it is not uncommon to have Controllers 'delegate' between Views and Models (like in 2/ below), but apart from that it is still useable. 2 cents of my own: I am not sure I would put URI rewriting in the middle like that. The main reason is that URI rewriting doesn't work with XDBC. It could mean that you have to come up with alternative logic to work with XDBC app servers. I tend to prefer doing things only once and in one way only.. (you can call me lazy.. :-P) I am not sure either that Model and View would be that difficult to distinguish. A Model can be reused by anything else, meaning any kind of View, any kind of Controller, and perhaps even other applications or logic. Everything concerning presentation is part of Views. This should make clear which layer belongs where. I could easily imagine though there is functionality that could be shared among different Views, but that doesn't make it part of the Model.. ;-) No offence, it was valuable to mention MVC, good pointer! Kind regards, Geert > Drs. G.P.H. Josten Consultant http://www.daidalos.nl/ Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 http://www.daidalos.nl/ KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. > From: [email protected] > [mailto:[email protected]] On Behalf Of > Florent Georges > Sent: dinsdag 15 december 2009 17:54 > To: [email protected]; General Mark Logic > Developer Discussion > Subject: Re: [MarkLogic Dev General] Towards a more modular > app architecture ... > > Lee, David wrote: > > Hi David, > > > Any other suggestions ? > > I see a web application in MarkLogic as any other web > application. So I like to apply the MVC pattern. So to name > concrete things: > > 1/ I use the URI rewriting support to dispatch the original > request to a controller (for instance myapp/* to the myapp > controller, myapp2/rest/* to the myapp2 REST controller > and other myapp2/* to the myapp web controller). > > The problem is that the original request (especially the > original request path) is not passed to the module > redirected to. The later see the exact same request it > would see if called directly. If you know you never use > query parameters, you can pass infos from the original > request as query params, in the URI rewriter; > > 2/ there can be several kind of controllers, most notably > traditional "web" controllers (returning an HTML view to > be view by a human on a desktop browser), REST controllers > (getting and returning XML) and binary files (returning a > binary file from a BLOB in the database). > > But all do the same basic things: computing a target from > the initial request path (aka the model), invoke it (to > get the actual model value), then applying a view to its > result; > > 3/ the view can be nothing or very simple (as in the case for > a binary file, it can do nothing or just set the result > code and Content-Type), or be more complex, like a > complete transform pipeline. I look forward to the next > version of ML, to be able to use XSLT here, and on a > subsequent version to even use a complete XProc pipeline > here ;-) > > The limits between the model and the view are not so > clear. For instance, you can define several layers: the > business entities (aka what you have in your database: > invoices, users, catalogs, items, etc.), a widget system > (components to add, select, delete entities), an abstract > page layout (made up of paragraphs, emphasys, lists, > titles, etc.), the actual HTML of the page core, then the > complete HTML (the core augmented with menus, header, > footer, etc.) > > A model will typically return elements of the lower layers > (entities, or an abstract page), but whatever it returns, > that will go through the pipeline to transform it to the > actual final, complete HTML page... > > Each step / layer / component / page can then be (more) > easily tested, and evaluated from the outside of the server. > > What misses now in XQuery is a solid description of how an > HTTP request is mapped and dispatched to a "component" (here > an XQuery main module). If we had that, it would be possible > to write frameworks implementing those concepts as > third-party frameworks (say like Struts for Java EE back 10 > years ago). Now, you have to write all that boilerplate code > yourself. > > Just my 2 cents... > > Regards, > > -- > Florent Georges > http://www.fgeorges.org/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
