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.
