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.
