On 5 December 2012 07:33, Chris Withers <ch...@python.org> wrote: > The closest thing I can think of is the move to the component architecture > that Zope did from v2 to v3; architecturally brilliant but actually killed > off the platform...
ROTFL! I have to admit my first thought on reading that page and diagram was "architecture astronauts"... If you're building a system which will last many years and tie together a core business, AND it really needs a rich internal object model embodying "business rules", yes, maybe this approach is valid. A core ERP system or some kinds of financial modelling systems spring to mind. Basically, a project which can justify a core team of 3-6 people working on it long term. But if you really need a company database, and a variety of web front ends and interfaces to it including CRUD, and budgets/timescales are limited, then there are huge efficiency savings all round for trying to do things "by the book" in Django, and using models as your business objects. New developers know where to look for things, and a lot of so-called business rules are easily implemented by save methods and signals. And there are established best practices for testing. This week we had to help an overseas firm add a reporting capability to their Django app. They sent over a copy of the code, and their development practices were amazingly similar to ours, and we had it running in an hour or so. Everything was where you expected to find it. If we had needed to trace through 3-4 layers to understand where one factoid came from, life would be a lot harder. I do fully agree with having an agreed dependency graph. We will often centralize the 'non-Django' parts of an application as helper functions inside a python module, inputting and returning just primitive Python tests, and write unit tests for those. But that's more a matter of having a well written "utils.py" in an app than of reimplementing everything outside of your framework. Cooperating web services have also helped deal with the interfaces problem. Big hairy corporate systems are often broken down now into reasonable sized chunks that POST and GET to each other, so you don't need quite so many layers and adapters in the code of any one of them. Just my grumpy-old-man 2p worth. -- Andy Robinson _______________________________________________ python-uk mailing list python-uk@python.org http://mail.python.org/mailman/listinfo/python-uk
