shocks wrote: > Hi > > I'm getting back into Python after a long break. I've been developing > large enterprise apps solely with Adobe Flex (ActionScript) for the > past couple years. During that time I've used a number of 'MVC' > frameworks to glue the bits together - among them Cairngorm, a > modified implementation of Cairngorm using the Presentation Model > pattern, PureMVC, Mate (an IOC container but with an MVC > implementation) and Parsley (IOC but you have to roll-you-own MVC). > During that time I've been in large teams (30 Flex + 30 Java) to small > teams (2 Flex + 1 Java). The motivation of these frameworks is the > decouple your concerns, allowing your apps to be more scalable, easier > to test, and supposedly easier to maintain. Some do the decoupling > better job than others, but there is also the question of "how > decoupled is your code from the framework"? It's all well and good > having something clever working behind the scenes wiring and routing > everything together, but I wonder where this leaves the code base if > the framework, which was selected at the beginning of the project, is > replaced with something else months or years later (i.e. the framework > just doesn't scale as expected, the community involvement dies and > it's no longer maintained properly, etc). I've seen it happen and > I've been experienced the pain of detangling massive amounts of code > which is full of framework specific imports, methods and boilerplate > code. And then there's updating the unit tests! > > My question is how good are the current crop of Python frameworks? > I've used Django twice in production and didn't like that much. The > implementation is Django specific for starters. I've picked up Pylons > and I'm trying that out. I'm not sure how well it fares? I do feel a > bit uneasy about the code generation that some of the Python > frameworks do. Pylons creates something like 20 files for a > 'helloworld'. It does do some great things out of the box, but I > wonder where that leaves your own code. After spending 3-6 months on > your Pylons webapp, how easy is it to move to something else? Maybe > one of the Python IOC once they mature. What are some good techniques > people are using to future (framework) proof their apps? > > I'm interested to hear people experiences with the various frameworks > and how decoupled their code is from them. The best of the current > Flex frameworks for me is Parsley. The only noticeable Parlsey code > is an '[Inject]' meta tag here and there and a couple import > statements. All the complicated object creation and messaging is done > higher up the chain.
I think the Pylons and maybe even TurboGears2 stack are pretty good regarding decoupling. This stems from them bundling "best-of-breed" solutions for e.g. ORM (SQLAlchemy), session-handling, HTML-widgets, templating and so forth together. So in theory, and to a large extend in practice, you can rip out individual components and replace them with ones you prefer, and of course this overall design makes things more decoupled. *However* there is only so much a framework can and does do when it's supposed to stay out of your way. I for one think that e.g. the repoze.who/what stack is an example of an over-generalization that leads to much more hassle than it's worth it, all for the alledged advantages of total decoupling and pluggability. Mark Christensen wrote a blog-post about the whole coupling/de-coupling issue: http://compoundthinking.com/blog/index.php/2009/11/28/coupling-django-style/ Essentially, getting things *done* now is very important, and making developers permanently jump through hoops just so they avoid coupling leads eventually to something that is your own webframework - without the benefit of participating on evolution of a common one that occasionally forces you to adapt. Diez -- http://mail.python.org/mailman/listinfo/python-list
