Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
No, a model is much more than "just" the data (even with triggers an all). The model usually uses a data layer to talk to the storage mechanism which may not even be a database. Also MVC is a very specific pattern for UI separation but separation of UI and business logic can be achieved in more ways than MVC. So yes, calling separation of UI and business logic MVC is absolutely unfair if you are not actually following the MVC pattern. Call it what it is: the database or the document, or in more generic terms: the storage. – Marjan Venema Aug 3 '13 at 20:17
"usually", "just" -- I'm not asking "is the model always just the data." I'm asking "is it fair to just call the data the model, and not bother building a pointless intermediate layer"? (And more importantly, WHY isn't it fair?) – DougM Aug 3 '13 at 22:09
up vote 2 down vote accepted

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.

share|improve this answer
Does a view ALWAYS have to be updated when the model changes, or only when there is a substantial revision? (i.e., if I tack-on a "lastEditBy" tracking internally bound to the current user account, just in the model, does the View need to be adjusted even if the app itself will never see the information?) – DougM Aug 4 '13 at 23:44
@DougM: Its a pattern not an implementation. It shows you how the data flows. But if we are talking about an implementation then usually you register views with the model so that when the model changes the views are notified. It is up to the view to decide what to change in the user interface (if anything). – Loki Astari Aug 5 '13 at 0:01

I don't think it's really important how you would call this or that, as long as you get MVC separation of concerns in a correct way.

In my opinion, MVC as a term is only related to code, not to data it's processing. In your example, DB would be storage, while model is whatever in your code "opens" and "exposes" this storage to other parts of your program (ie. controller).

share|improve this answer
In FoxPro or Access, or even Excel and Word, it's not uncommon for a control to be created, a field defined, and the two data-bound together without a single line of code being written. For what it is the process works acceptably well... most of the time. – DougM Aug 5 '13 at 12:32

Yes, that's a fair assessment and really isn't too far from Rails' Active Record pattern. MVC is a UI pattern, and doesn't really care how you structure your domain layer - just that you keep it separate from your View and the UI action handlers (the Controller).

With that said, what you're describing would probably fall under an anemic domain anti-pattern - that's fine for an awful lot of applications, but you should watch out for the pitfalls as well. The main one being the tendency for the Controller to pick up the slack and start absorbing logic that should belong to the domain (such as validation or orchestration). Or the growth of a service layer that lives beside the domain and contains all of the logic.

share|improve this answer
I'm actually most worried at this stage about not having ANY sensible patterns. "THIS.pgFrame.page1.txtThing.value" is prevalent, and only the shortest example. – DougM Aug 4 '13 at 23:42
@DougM - that sounds more like an issue at the Controller and View side of things than the Model. I'm not real familiar with recent vintage VFP or Access, but a common pattern for stuff like this would be data binding. Not exactly MVC (actually MVP) but effective if your tooling supports it. A more MVC approach would be to segment down to subviews and subcontrollers (eg., a controller for just page1 handling txtThing and a controller for pgFrame managing all of its subcontrollers). – Mark Brackett Aug 5 '13 at 3:07
Yes, exactly. The model, by and large, is workable. it's the co-mingling of the view and controller that is most alarming. – DougM Aug 5 '13 at 12:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.