On 05/12/2012 13:08, Michael Foord wrote:
On 5 Dec 2012, at 07:33, Chris Withers <ch...@python.org> wrote:
On 04/12/2012 17:46, Menno Smits wrote:
On 2012-12-04 14:46, 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.
Since you mentioned this a few weeks back, I've been thinking about this
approach a lot and doing a fair bit of background reading on the idea. I
think it falls in to the brilliantly-obvious category, at least for any
app of significant size. I plan to start using these ideas for my next
big work project (not Django however). Previously, I've tended towards
less flexible, harder-to-test, layered architectures.
The biggest concern I have with this approach is that it appears to preclude
taking advantage of any features of your storage layer. If your business
objects have to not know or care about their underlying storage, how do you
take advantage of nice relational queries, stand alone text indexing service or
other specific features of the architecture you've chosen?
I guess you still need to provide an abstraction for these features, even if
only one backend supports the abstraction.
What I'm reading suggests that if, for example, your app needs to use a
text indexing service, then that's an external system and your
application core should define an API which it will use to talk to it.
So you still get to use features like this, but you are obliged to put
an API layer (and possible inversion of control) between them, rather
than making the call directly from within your business logic.
Similarly, if your business logic needs a small number of particular
relational-type queries, then perhaps those queries should be the API
defined by your core for talking to persistence. If your app needs many
such queries, or general-purpose relational querying support, then
perhaps you can create an API which supports general purpose querying
such as the 'repository' pattern.
I'm no expert. The above is my newfound understanding and some speculation.
There's also the risk that you end up testing each bit (business, views,
storage) in isolation and never get around to doing the automated integration
testing required to ensure artifacts of implementation (*cough* bugs) don't
cause problems across those boundaries...
Well, you need integration / acceptance / functional / end to end tests
*anyway*.
Michael
That said, I'd love to see a project that's a good example of this, are there
any around online in Python? 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...
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing
http://www.sqlite.org/different.html
_______________________________________________
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk
--
Jonathan Hartley tart...@tartley.com http://tartley.com
Made of meat. +44 7737 062 225 twitter/skype: tartley
_______________________________________________
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk
