The controller pattern is awful, and other OO heresy (2013)
&gt; Stop writing <i>stupid</i> classes.<p>This is really it. It&#x27;s not a game of all-OO, zero-OO or strictly following a pattern you saw on YouTube that one time. It&#x27;s all about nuance and minimizing the # of moving parts until each is really serving you some value.<p>I am in the process of ripping out a bunch of class bloat in a product iteration. Our typical pile of model class POCO spam for &quot;one thing&quot;:<p><pre><code>  Entity.cs --The &quot;official&quot; view
  EntityController.cs
  EntityView.cs --Another common view that became popular over time (???)
  EntityTableRow.cs --gotta have that 1:1 sql model, amirite?
  EntityViewForTypeA.cs --what was wrong with the common one :(
  EntityViewForTypeB.cs --And again...
  ...
</code></pre>
Ultimately, every time we wanted a &quot;view&quot; of the data, we wound up creating another type to enshrine this and then tried to figure out how many holes we could more-or-less hammer it through. Every one of these has some cranky mapping layer too (NxM if you want to get crazy).<p>The alternative pattern I am working with is to directly query my database in the exact place the data is required and to use anonymous &#x2F; scalar return types like so:<p><pre><code>  &#x2F;&#x2F;Some function that produces a HTML partial view for a webapp

  &#x2F;&#x2F;View w&#x2F; join that would otherwise require a new POCO type to communicate.
  var myEntityView = await sql.QueryFirstAsync(@$&quot;
    SELECT e.Id AS Id, ep.Name as Name
    FROM Entities e, EntityProperties ep
    WHERE e.Id = ep.EntityId
    AND e.Id = @Id&quot;, ...); 

  &#x2F;&#x2F;Direct usage of anonymous result type.
  return $@&quot;
    &lt;h3&gt;Entity:&amp;nbsp;
      &lt;a href=&#x27;Entities&#x2F;{myEntityView.Id}&#x27;&gt;{myEntityView.Name}&lt;&#x2F;a&gt;
    &lt;&#x2F;h3&gt;&quot;;
</code></pre>
In the above, there are <i>zero</i> POCOs or &quot;messenger&quot; types. Just a raw query right where it needs to be taken, without any extra ceremony or implications for other code sites. I actually don&#x27;t have a single type in the new codebase that is a POCO, other than schema tracking models (which are still useful for interpolating into queries to enforce magic strings). Effectively, the only domain data types are 1:1 with the SQL schema now.