On Tue, 2012-12-04 at 14:46 +0000, Jonathan Hartley wrote: > I haven't, yet, but I'm thinking of refactoring a vertical slice of > our monster Django app into this style, and I'd love to hear if you > think it's crazy / brilliant / obvious / old-hat, etc.
All three, I suspect. Abstraction and properly designed APIs are always good, and I guess the layered structure occurs quite naturally. (or, perhaps, _should_ occur quite naturally?) My own difficulty with these structures comes from the business logic part. There's four aspects of this - the choice of what goes on the form presented to the user, the validation of user input, the logic of what happens when a button is pressed (calculations and storage), and the choice of what the user sees next (business process). The middle two can clearly be devolved to a business object, and the outer two can be _supported_ by a business object, but, it seems to me, there is always something 'businessy' in the user interface parts. My experience here is, admittedly, limited, so I'm probably missing something. I'm currently using a version of MVC, with components. I partition the source along business lines with appropriate parts (components) going under the headings of M, V, or C as appropriate. Creating a new business object or process can be a bit mind bending, but, generally, the bits fall into the places where you might expect them. None of this (for certain values of None) generates html directly, so, in principle, and within limits, I can customise what the user sees. So, I think I have separated concerns where this is possible, and not done so where it's just too difficult. Business logic is packaged in a way that makes it accessible, and, at the same time, recognises that the presentation is a factor. My conclusion, for what it's worth, is: layering is good, but don't be officious :-) Mike S. _______________________________________________ python-uk mailing list python-uk@python.org http://mail.python.org/mailman/listinfo/python-uk
