I once had abstracted a complex application as a directed graph that have only nodes and edges. From there I STIed most of my business entities.
The resulting app had only two tables and complexity relating to the network was nicely separated from business objects. Which was kind of beautiful.
Now, about testing. Testing of controllers is the key, you say?
Strange enough, I think that unit tests (models) are the most important. Because controllers are dumb, and often they are not even the only way to access the logic.
What if your application is called by some AJAX framework that has its own MVC built-in, like Dojo?
If the design is right, I can get all of my app's functionality from command line, ignoring the controllers completely.
I've got mixed feeling about STI. We're using it for one of our larger projects with success. I don't like that they recommend polymorphism for everything; this makes iterating collections of the interface very difficult.
Controller tests are actually really important for a few reasons; one of the more obvious being user authentication. While our controllers tests are anemic when compared to our model tests, we do test the more heavily used controllers.
Sounds good: "Although unit tests can be important for iterating features, for most young Rails apps, models are more simplistic. What you should make sure of is that all points of interaction for users are well tested, and stay un-broken from release to release.", but is plain bad. With REST controllers and multiple formats, it is a bad idea to not follow the Fat Model approach.
I store a data grid, of which there are two types of headers. Row and column headers. (Headers must be their own object for various reasons that are rather boring).
Rows and columns have identical fields. Voila! STI is actually kind of useful!
As for the rest of the article, it seems reasonable but not mindblowing. Good to keep in mind though.
I once had abstracted a complex application as a directed graph that have only nodes and edges. From there I STIed most of my business entities.
The resulting app had only two tables and complexity relating to the network was nicely separated from business objects. Which was kind of beautiful.
Now, about testing. Testing of controllers is the key, you say?
Strange enough, I think that unit tests (models) are the most important. Because controllers are dumb, and often they are not even the only way to access the logic.
What if your application is called by some AJAX framework that has its own MVC built-in, like Dojo?
If the design is right, I can get all of my app's functionality from command line, ignoring the controllers completely.