I like the question mark at the end of hammet's subject. I do not get why the internal modelling of a system (actually of a certain bounded context within a system) should be reflected in the public http API 1:1 With the many web sites and applications that I've built in the past years, using MonoRail, MVC, Rails and some other fwks, I always ended up using custom routing rules as anti-corruption or facade or whatever to decouple the http-exposed interface from the internal structure of the system, allowing flexibility when refactoring etc. I even avoided the Controller/Action rule. This one always has a cost of "how to model my controllers to reflect public api" instead of following OO principles for that.
my point - there should not be a dependency between controller hierarchy and routes to begin with. If anything, the disruptive thing to do is to eliminate the controller/action rule. I'd also dis-allow mapping overloaded actions to routes, making the action selector code (one of the more complex parts of MR1-2 imo) trivial, and eliminate many "surprise" bugs in usage scenarios. Ken Egozi. http://kenegozi.com/blog http://social.sears.com http://www.musicglue.com http://www.castleproject.org http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם On Sun, Oct 30, 2011 at 2:30 PM, Sebastien Lambla <[email protected]> wrote: > 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. > > -- 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.
