Interesting. But controllers could also be hierarchical right? I wonder if it's a good idea to have controllers that only make sense as children (cannot be executed on its own) and how to express this relationship.
I also have two difficult requirements: - Ideally this "hierarchization" should be inferred statically - meaning that I dont need to execute any code to figure out the "tree" (this is required if I need to build odata metadata, wsdl and etc) - While module A can have Account, Subscribers, and Lines, it would be great if Module B - which is a third party - could plug branches into Account, say, offering Account/Profiles Challenging but fun :-) On Sun, Oct 30, 2011 at 5:32 AM, Markus Zywitza <[email protected]> wrote: > I'd like to model this as a hierarchical resource access: > > /Account/1002/Subscribers/1/Lines/425-555-1010/ > > URI's head is /Account/1002, tail is /Subscribers/1/Lines/425-555-1010/ > > So look for a handler that fetches an account by id and execute it. > Now we still need a way to handle the tail of the URI. This can be > done inside the account handler. The handler can try to match the > URI's tail to its subhandlers' routes and forward the request along > with the fetched account. > > This is the DDD route with an aggregate root that is responsible for > forwarding a subrequest on its own. It requires you to build a handler > hierarchy that matches the aggregate's hierarchy. > > This is recursive: > > The subhandler has access to the aggregate root and handles > "/Subscribers/1" by fetching the subscriber using appropriate methods > of the aggregate root. Then it looks for a subhandler that can handle > the tail: /Lines/425-555-1010/ > The "Lines" handler has a reference to the root and subscriber object > and gets the requested line from the subscriber object. It then > handles the tail which is "/" in this case. This tail is a command, > most likely GetInfo() or similar, but it could also be "terminate", > which accepts a post request for terminating a line: > /Account/1002/Subscribers/1/Lines/425-555-1010/terminate > > After you have found the requested resource, it must be somehow > rendered as a web page. This is done by the handler returning a view > model, that is displayed by applying it to a view. > > I have written handler instead of controller, because I don't see it > as a traditional MVC pattern anymore. It is rather enhanced REST (REST > is CRUD over http and this model allows arbitrary commands in addition > to CRUD) than a MVC triplet. > > -Markus > > 2011/10/30 hammett <[email protected]>: >> 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 :-) >> > > -- > 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.
