Part of my job is working on line-of-business applications built around client-side databases, such as Access or FoxPro.  Other times these local LOBA's have direct document access, such as an exact one-to-one mapping between a logical object an an XML node or references to bookmarks in Word Documents or ranges Excel spreadsheets.While the code is about as messy as one would expect, it's usually fairly stable and the platforms these applications are built upon all have one thing in common: they translate program data to physical storage directly and transparently, from the programmer's point of view.Would it be fair to refer to the database or document in one of these LOBA's as a Model, when referring to the Model/View/Controller separation of concerns?  Or would it be improper to call separation of UI and business-logic MVC unless we make intermediate objects that in turn map to either the UI or the database?
Is it fair to call a database or a document a Model, as in Model/View/Controller?
design patterns;mvc
MVC is a design pattern.They (design patterns) are not meant to restrain you in how they are used and/or implemented. They are supposed to be a communication mechanism that allows you to convey ideas about your application to other programmers (not an implementation).And though normally I would expect the model to be more than just data (as the view needs to be updated when the model changes). But as a documentation or description processes I would be OK with you referring to the Data as the model as long as it helps you explain how the system works.