I really don't get ASP.NET MVC because the entire point of the Model is to interact with the database through C# code (or any other language that gets compiled to the CLR) and yet I know it's possible to, and considered good practice to, write all your business logic in the database to the point where the only thing your C# code does is say "Go!", making LINQ and all that fancy jazz pointless. Let me give a real-life example. I'm writing an application that has a table representing comments in a comment thread and another table representing ancestor-descendant relationships of said comments. When a new comment is created, a new ancestor-descendant relationship is created as well (If the comment is at the top-level, it's ancestor is itself). When a comment is deleted, all its ancestors are deleted as well as the map of their relationship in the other table. I can make all this logic possible with sprocs, triggers, etc. when I set up my database. Or I can just create the tables in as static a form as possible and use my C# model to handle the aforementioend logic. By doing as much on the database as possible, the problem is that if I decide to revise or add anything to the database, including sprogs/triggers/cascades/etc., my C# model is out of sync and I have to regenerate it based on the updated database and rewrite all the C# code that was handling the logic. The advantage is (supposedly) efficiency from not having raw queries thrown at the database. On the other hand, if I keep all that complicated in the C# code then it's less work to maintain when the database is changed because I don't have to do all this again. In short, I don't know how to justify an MVC model if I'm a SQL expert (which I'm not but hope to be some day). It's like a reversal of traditional roles: The database handles the programming logic and the language of the model (C#, VB, etc.) acts as a talker that sets the logic in flow.