You may want to have a look at snooze, they experimented with those kind of ideas 3 or 4 years ago ________________________________________ From: [email protected] [[email protected]] on behalf of hammett [[email protected]] Sent: 30 October 2011 01:24 To: [email protected] Subject: Re: Disruptive design needed for next gen of web frameworks (?)
many aspects play into this picture. you mentioned two of them (OOP and storage). But there's also DDD (Account may be the aggregate root, so there's no way to access entities bypassing the account), authorization (user x cannot load this account or view this subscriber).. That's why I believe these aspects should be modeled and visible in a hierarchy, instead of route configurations. I'm just very unclear on how to actually do it :-) On Sat, Oct 29, 2011 at 5:49 PM, Rafael Teixeira <[email protected]> wrote: > I can only think of this kind of composite route occurring when we model > data in a NoSQL fashion where not every piece of data is guaranteed to have > an unique (primary key). > If you guarantee unique keys for each object in the model, we just use pure > REST for navigation and thus get back to 'flatter' routes: > /Lines/123123189 is line 425-555-1010 of subscriber 1 of account 1002 > Even on a NoSQL scenario we can imagine that the lines controller can't > truly work on second-level nested data of a document, so it would be > possible to just map a route with a composite key > /Lines/1002/1/425-555-1010 > The problem which is also a problem on object-modeling x document-modeling > is really if you have multiple navigations, relations on SQL, to arrive at > the "Line" data... > Not sure I helped to think into the proposed question, but I think we should > consider if RESTfulness is a driver and also SQL/NOSQL optimization, as > those may drive away from the nested routes scenario. > Just my fried brain cells speaking, > Fun, > Rafael "Monoman" Teixeira > --------------------------------------- > "The most exciting phrase to hear in science, the one that heralds new > discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" > Isaac Asimov > US science fiction novelist & scholar (1920 - 1992) > > > On Sat, Oct 29, 2011 at 10:05 PM, hammett <[email protected]> wrote: >> >> I'm starting to think that this flat representation of resources in >> the rails-style breed of MVC frameworks is quite deficient for today's >> requirements of apps. A domain is hardly flat, and the deeper you get >> the more context you need >> >> For example >> >> /Account/1002/Subscribers/1/Lines/425-555-1010/ >> >> With today's framework's you'll end up activating the Lines >> controller, passing an id. What Account/Subscribers and their ids? One >> trick is to pre-load those by using hierarchical routes. MR3 routing >> supports this. The issue I have is that this is too decoupled from the >> controllers (they continue to be flat) >> >> Using Routing >> >> For("/Account/:id").Config(c => { >> c.For("/Subscribers/:id").Config( c2 => { >> c2.For("/Lines/:id") ... >> }); >> }); >> >> We could potentially pre-load each account, subscriber and pass it >> along to the LinesController, but I'm not convinced this is a good >> design. >> >> Thoughts? >> >> >> -- >> Cheers, >> hammett >> http://hammett.castleproject.org/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Development List" 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/castle-project-devel?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" 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/castle-project-devel?hl=en. > -- Cheers, hammett http://hammett.castleproject.org/ -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en.
