Add a comment

 

Re: The delivery mechanism is an annoying detail

I found your points interesting. Uncle Bob doesn't give you the whole answer. And I am quit sure that is by intent. You don't want to lecture people om which pattern approch you want your readers to use because that would derail the main message in the talk; that the use cases should be in the center of the architecture, not frameworks, not delivery mechanisms and not patterns. Although the patterns may help you. I was just now searching the web for an answer to the same question you where having. (How to isolate the delivery mechanisms from the application) And I think I found the obvious answer. One way of isolating the delivery mechanism is by using ports and adapters: http://alistair.cockburn.us/Hexagonal+architecture Alistair Cockburn has a very good explanation on how you can go about using it. So if you where to use a rail framework then you would have to extend your controllers with an interface that you would have adapt your application into using by writing an adapter for using rail framework., Delegation of workflow , inversion of dependencies/dependency injection and/or service locator, maybe also pipes and filters if you need to use events, would have to be used to be able to make it work depending on the complexity of your application. I think what uncle Bob is saying, is that there isn't one solution out there, but a collection of them that you would have to apply in the right order and context.

Re: The delivery mechanism is an annoying detail


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).