It wasn't an interpretation of MVC per-se but more of what I think the Model in any architecture should be. The Model can be used in MVVM and MVP as well and can be part of DDD way of doing things.
And again, for me, a model should be a representation of an object/data. If it is tied to an ORM (Active Record or Entity Framework) it may come with DB access, but I still don't think models should contain application specific logic. That's what the 'Business' layer should be for. If an Invoice model knows about tax codes from 130 different countries, again I think it knows way too much about the application.
As I see it, the Model in MVC is everything that is not C or V. It encompasses the service layer, the DAOs, the data objects and what have you.
The term Model on it's own doesn't mean much, and is very overloaded with meaning. You can see it as the data objects (stuff like Person(id, firstName, lastName) for example), but that's one definition of it.
Seriously, you've got it very wrong. A model is not 'a representation of an object/data'. It's the whole business domain. MVC is about separation of the UI from the domain and the controllers' the intermediary.
Not sure which pattern you're thinking of, but it's not MVC.
And again, for me, a model should be a representation of an object/data. If it is tied to an ORM (Active Record or Entity Framework) it may come with DB access, but I still don't think models should contain application specific logic. That's what the 'Business' layer should be for. If an Invoice model knows about tax codes from 130 different countries, again I think it knows way too much about the application.