1

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?

Improve this question
2
  • 1
    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
    Commented Aug 3, 2013 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
    Commented Aug 3, 2013 at 22:09

3 Answers 3

Reset to default
2

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.

Improve this answer
2
  • 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
    Commented Aug 4, 2013 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
    Commented Aug 5, 2013 at 0:01
2

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).

Improve this answer
1
  • 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
    Commented Aug 5, 2013 at 12:32
1

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.

Improve this answer
3
  • 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
    Commented Aug 4, 2013 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
    Commented Aug 5, 2013 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
    Commented Aug 5, 2013 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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