title: Lithium apps that go beyond CRUD
body: <p>This is more or less a framework-centric version of a <a href="https://stackoverflow.com/questions/267094/multiple-table-models-with-mvc">past Stack Overflow question</a>, which is about how most introductory material on MVC applications tends to present a tight coupling between models, views, and controllers. For example, you'll have a User table that is modified by a User controller which in turn pushes filtered data to a User view. It's my impression that a lot of MVC frameworks tend to reflect this pattern as well. This is all fine and well for what it is, but it never really leads me to anything beyond building and displaying monotonous lists of things with an HTML form.</p>
  
  <p>The MVC framework that looking at right now is <a href="http://lithify.me" rel="nofollow noreferrer">Lithium</a>, which seems quite interesting as a case study of clever PHP5.3 coding techniques. On one end, Lithium has a <code>Model</code> class that offers wrapper objects around a individual tables, and abstracts away some simple queries. On the other end, it's got a nifty convention of routing URLs to method calls on controller objects, which then render to display templates.</p>
  
  <p>But in the midst of this, I find myself at a loss as to where to place all of the interesting logic that relates data in table A to data in tables B through Z. Or at least, I'm not sure where to place such logic in a manner that's consistent with the design of the framework. To my understanding, Lithium's <code>Model</code> abstraction doesn't do much more than eliminate some row-level insert/update/delete boilerplate, and the controller/view architecture seems mostly about user interface. I wouldn't want to put a lot of business logic in the same <code>Controller</code> class that is receiving routed function calls from URL requests.</p>
  
  <p>My instinct would be to fill the gap with a bunch of my own code that exists more or less entirely outside of the framework. I'm not sure if I ought to expect more than that, but given how rigidly structured everything else is in Lithium, it feels somehow unsatisfying, like I could have just rolled my own boilerplate-reduction code without the overhead of grokking the source of a big framework.</p>
  
  <p>What am I missing here? Is there a recommended architecture or philosophy to using this type of framework?</p>