Timeline for MVVM and service pattern
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 4, 2013 at 21:36 | comment | added | Aaronaught | Also, I would take issue with the statement that "the best architectures evolve from friction". Architectures don't evolve, they are designed. Code evolves, and it can evolve because it can be refactored. However, re-architecting is a significantly more painful proposition than refactoring, and if you don't pick the right architecture to start with, you're going to be fighting an uphill battle for a very long time. It's pretty easy to move a method into a different type, but you can't switch from Oracle to Riak in the middle of a project. | |
| Nov 4, 2013 at 21:35 | comment | added | Aaronaught | I understand your argument; what I'm arguing is that the façade doesn't make the design better, it makes it worse. You have exactly the same number of dependencies, but now they're harder to keep track of. It would be far better to just leave the design the way it is, and have the pain reminding you that the view models aren't following the SRP, vs. chucking it all into a façade and instantly losing track of what really depends on what else. | |
| Nov 4, 2013 at 21:25 | comment | added | Michael Brown | I didn't say it was the perfect solution, the facade should only dispatch the message to the appropriate service. I think the best architectures evolve from friction. Once people have friction with a single facade, they will want to break it down into more focused services. But these would be scenario based services rather than the fine grained services that the OP currently has. The facade should be protected from changes to the details of its services because those details are hidden behind the service. It's an extreme approach but fundamentally better than working from the other way. | |
| Nov 4, 2013 at 21:08 | comment | added | Aaronaught | I think part of the confusion here - and I see this quite a lot - is just what a dependency means. If you have a class that depends on one other class, but calls 4 methods of that class, it has 4 dependencies, not 1. Putting it all behind a façade doesn't change the number of dependencies, it just makes them harder to understand. | |
| Nov 4, 2013 at 21:07 | comment | added | Aaronaught | This is very different from a message broker because the broker also knows nothing about the implementation of the message handlers. It uses IoC under the hood. The façade knows everything about the recipients because it has to forward calls to them. The bus has zero coupling; the façade has obscenely high efferent coupling. Almost everything that you change, anywhere, will affect the façade as well. | |
| Nov 4, 2013 at 21:04 | comment | added | Aaronaught | Yes, but the façade is then a God Object. It has all of the dependencies that the View Models have, probably more because it's going to be shared by several. In effect you've eliminated the benefits of loose coupling that you worked so hard for in the first place, because now, whenever something touches the mega-façade, you have no clue what functionality it really depends on. Picture writing a unit test for a class that uses the façade. You create a mock for the façade. Now, which methods do you mock? What does your setup code look like? | |
| Nov 4, 2013 at 20:57 | comment | added | Michael Brown | The similarity is that the facade acts like a router, the caller doesn't know which service/services handles the call just like a client sending a message doesn't know who handles the message. | |
| Nov 4, 2013 at 20:48 | comment | added | Aaronaught | A massive service façade is very different from a message broker. It's almost at the opposite end of the dependency spectrum. A hallmark of this architecture is that the sender knows nothing about the receiver, and there may be many receivers (pub/sub or multicast). Perhaps you're confusing it with RPC-style "remoting" which is just exposing a traditional service over a remote protocol, and the sender is still coupled to the receive, both physically (endpoint address) and logically (return value). | |
| Nov 4, 2013 at 19:43 | history | answered | Michael Brown | CC BY-SA 3.0 |