>-----Original Message----- >From: Ate Douma [mailto:[email protected]] >Sent: Thursday, June 28, 2012 8:23 AM >To: [email protected] >Subject: Re: [Proposal] Model Isolation > >On 06/28/2012 10:35 AM, Scott Wilson wrote: >> On 28 Jun 2012, at 03:41, Chris Geer wrote: >> >>> On Wed, Jun 27, 2012 at 6:50 PM, Franklin, Matthew B. >>> <[email protected]>wrote: >>> >>>> Chris asked the question in the past if we wanted to move all models to >>>> using IDs to reference related objects. I think this approach makes sense >>>> in certain cases and tight coupling makes sense in others. I have put >>>> together a proposal for a balanced approach in the wiki [1]. >>>> >>>> Given that each of these changes should be isolated enough, I think we >can >>>> safely do this in trunk one class at a time. >>>> >>>> Thoughts? >>>> >>> >>> I think we could even get away with combining Page and Widget groups. >Those >>> are pretty tightly linked and probably won't be separated. >>> >I think I can agree with that, for now. >Although the sizing and scaling of the Page group might be very/extremely >different from the Widget group. So separating these two might still be >needed >or at least considered.
I think they need to be separated for the simple case that you want to define your widgets in a separate store from your pages. I can see wanting to keep Widgets in SQL while pages in a document store. Also, if you want to connect to a separate widget store like edukapp, the widget model needs to be separated. > >I made a small update to the group definitions: I moved the PageTemplate* >types >to a separate Page Prototyping group. AFAIK these have nothing so much to >do >with Page Rendering but are only used as 'prototype' when creating new >Page* >instances. Or maybe I misunderstood why the PageTemplate* types were >grouped >under Page Rendering? Prototyping is better. I only called it Rendering because I included the layout, which is more of a runtime rendering pointer. > >Anyway, I'm working on an alternate dynamic and hierarchical >PageDefinition/PageFragment model for the content-services sandbox which >I >intend as replacement for all the Page* groups. IMO the current model isn't >going to scale or be maintainable so *some* changes will be needed for sure. > It should be a good start to isolate this then, right? How close do you think you are to proposing that model? I was hoping we could started on this next week at the latest... > >>> One thing to consider though is how does a tightly coupled data model >work >>> for the various APIs? I've only done a little research but it looks like >>> the REST API returns/accepts a pretty shallow data model. Would that >cause >>> problems with a richer backend data model? >> >> I think it may make sense to decouple the REST API data model from the >underlying model with some DTO classes representing just the data we want >to expose. >> >Yes, agreed on that. > >Related to this, I've spend last week some time looking into the project Qi4j >project [1] and the underlying DDD [2], DCI [3] and CQRS [4] theory and >practices. > >Although I think they (Qi4j) are on the right track and this potentially might >be good for us (Rave) to look into, I also think its a bit too much and to far >reaching right now to pick this up. >Nonetheless the links below are recommended to read into if your >interested. > >[1] http://www.qi4j.org/introduction-background.html >[2] http://en.wikipedia.org/wiki/Domain-driven_design >[3] http://www.artima.com/articles/dci_vision.html > http://en.wikipedia.org/wiki/Data,_context_and_interaction >[4] http://martinfowler.com/bliki/CQRS.html > >>> >>> Chris >>> >>>> >>>> [1] : >>>> >http://wiki.apache.org/rave/ArchitectureTopics/Persistence/ModelIsolation >>>> >>>> -Matt >>>> >> >
