I was having a discussion with a colleague and he bought up the topic of MVC and the use of ViewModels in ASP.NET MVC.
The discussion was that, in an n-layer architecture, the UI, Business Layer and Data Access Layer are individual assemblies/projects and ViewModels are the UI's representation of a database/business object. The discussion on whether ViewModel's are useful moved into a discussion about how MVC should be applied.
In my version (which is what I am used to/have seen elsewhere) takes into account separation of concerns and waterfall dependencies, where the UI project references the BLL, the BLL references the DAL and possibly all of them reference an "Entities" project. "MVC" is restricted to the UI. That is, the notion of "Models" (in my version, they are technically just ViewModels), "Views" and "Controllers" are individual files/objects in the UI layer. The BLL talks in terms of database entities and the UI will generally contain helpers that map a ViewModel to an entity.
My colleague's version took this to the system/layer level, where the "Model" is the DAL, the "View" is the entire UI and the "Controllers" are the BLL as a whole.
Given that in an MVC triad, the Model is unaware of Views or Controllers, the Views know about Models and the Controllers know about both.. does the system-level application of MVC not violate modular programming concepts/code reusability (disregarding the possible circular dependency issues)?
Are patterns such as MVC applied at a system level often? My understanding was that MVC and related patterns were more often applied purely to the UI and not spread out across an entire n-layer system.
By the way, we had a look at this question: What is MVC, really?
..but we also seem to disagree on whose argument the answers to this question supports! :)
I could be just stuck in my little tiny .NET-oriented world and cannot see the bigger picture, so I would like to hear some thoughts on this.