I actually do organize my plugins as raganwald suggests...and, as we've rolled out more products, and I'm seeing increasing commonality in pieces between then, am thinking more and more than 90+% of every one of our projects should be all plugin code.
Raganwald is also mentioning refactoring the code so that the data objects become responsible for persisting and displaying themselves though.
I don't necessarily have any problems with the persisting (that's how ActiveRecord works out of the box), but I'm not sure about the displaying, because I sometimes want to display things differently depending on the context.
Well, I gave a very trivial example showing that, but I don't necessarily believe it should always work that way. Let me be more specific: If you have a Persistanceamajig that know the difference between an account and a customer, then you might want to break it up. On the other hand, if the Persistancamajig can do its job by inspecting the things you pass to it, then it may be a very good idea to keep its implementation separate.
Likewise if you want a separate Displaythingie that can work out how to display an account or a customer on its own, great. If it needs to know a lot about accounst and custoemrs to do its job, but you want to swap it out or paramaterize it (e.g. one set of views for iPhone, one set for Safari), the classic organization makes a certain amount of sense.
All that being said, I have built a large, public-facing app with multiple views for multiple devices, and my experience is still that we did modifications across all of the things related to a model much more often than doing modifications to all of the views across all of the application.
