Python PureMVC vs Pubsub [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

I'm creating a python application and I want to implement it with MVC in mind. I was going to use pubsub to accomplish this but I came across PureMVC.

Could anyone explain these two things to me, the differences between them and the implications of using the one over the other.

Answer 1

I presume you are referring to pypubsub which I know a lot about (I am the author ;). However I don't know much about PureMVC for Python.

The two are very different, based on the PureMVC docs. Here are some differences that I think would matter in choosing, based on browsing the docs and listening to the presentation:

• Learning curve:
  • Incorporating pypubsub in your app is easy: decide on "message topics", subscribe methods and functions, add send messages for those topics. Transport of the messages to destination is automatic. The "cruising speed" API is small: you have pub.subscribe and pub.sendMessage to learn and that's it.
  • with PureMVC you have to learn about mediators, commands, proxies, etc. These are all powerful concepts with significant functionality that you will have to learn upfront. You may even have to write a couple apps before you go from "knowledge" of their purpose, to "understanding" when/how to use them. For a one-of app, the overhead will sometimes be worth it. Most likely worth it if you create many applications that use the framework.
• Impact on application design:
  • PyPubsub: anonymous observer design pattern.
  • PureMVC: MVC architectural pattern.
  • There are no classes to use with pypubsub "standard use". Mostly you have to classify your messages into topics and decide what to include as data. This can evolve fairly organically: you need a new dialog, and need to make some of its state available so when change a field, a label changes somewhere else: all you need to do is include a publish in the dialog, and a subscribe in the code that updates the label. If anything, pypubsub allows you to not worry about design; or rather, it allows you to focus your design on functionality rather than how to get data from one place to another.
  • With PureMVC there are many classes to use, they require that you design your components to derive from them and register them and implement base class functionality. It is not obvious that you can easily publish data from one place in your application and capture it in another without creating several new classes and implement such that they will do the right thing when called by the framework. Of course, the overhead (time to design) will in some cases be worth it.
• Re-usability:
  • As long as a component documents what message topics it publishes, and what it listens to, it can be incorporated in another application, unit tested for behavior, etc. If the other application does not use pypubsub, it is easy to add, there is no impact on the architecture. Not all of an application needs to use pubsub, it can be used only where needed.
  • OTOH a PureMVC component could only be incorporated into an application that is already based on PureMVC.
• Testability:
  • PureMVC facilitates testing by separating concerns across layers: visuals, logic, data.
  • Whereas publish-subscribe (pypubsub) facilitates it by separating across publishers vs consumers, regardless of layer. Hence testing with pypubsub consists in having the test publish data used by your component, and subscribe to data published by your component. Whereas with PureMVC the test would have to pretend to be visual and data layers. I don't know how easy that is in PureMVC.
  • Every publish-subscribe system can become difficult to debug without the right tools, once the application reaches a certain size: it can be difficult to trace the path of messages. Pypubsub provides classes that help with this (to be used during development), and functionality that verifies whether publishers and listeners are compatible.
  • It seems to me based on PureMVC diagrams that similar issues would arise: you would have to trace your way across proxies, commands, and mediators, via facades, to figure out why something went wrong. I don't know what tools PureMVC provides to deal with this.
• Purpose:
  • The observer pattern is about how to get data from one place to the next via a sort of "data bus"; as long as components can link to the bus, state can be exchanged without knowledge of source or sink.
  • PureMVC is an architectural pattern: its job is to make it easy to describe your application in terms of concerns of view, control, and the data. The model does not care about how the control interacts with it; the control does not care how it is displayed; but the view needs the control to provide specific services to handle user actions and to get desired subset of data to show (since typically not all data available is shown), and the control needs the model to provide specific services (to get data, change it, validate it, save it, etc), and the control needs to instantiate view components at the right time.
• Mutual exclusion: there is no reason that I can think of, based on the docs, that would prevent the two libraries from being used in the same application. They work at different levels, they have different purpose, than can coexist.

All decoupling strategies have pros and cons, and you have to weigh each. Learning curve, return on investment, re-usability, performance, testability, etc.