MVC views stored in DB

Having used different MVC frameworks I always want to improve the searchability of views. I’ve come up with solutions for site search where the view files are checked for matches, but search is so much more simple if the views are stored in the database.

I came up with a solution where I can use both filesystem based views and database stored views, and I’m now considering how those views will be created, maintained, deleted, etc. I’ve got most of this planned out in my head, but wondering if others have done this, and have any advice. I’m not looking to create a CMS, but just a system of managing the views. Since I like to use Sublime Text 2 and Notepad++ I’m thinking to have a CLI type command to create a file that is paired with a DB record, then be able to edit the view in the filesystem, which upon another CLI command update the DB record.

I don’t see why there would be any problems with what I’ve got planned, but I’m interested what people think. Bad idea?

Hi skunkbad,

I’m not sure why you’d want to maintain a static page alongside content in the DB, what advantage would that give you? If you separate out your content from your page markup, you can store the content in the DB where it’s searchable, and put the markup into templates on the filesystem which you can modify in your editor. That’s a fairly common way to do things.

What do you mean “Searchability of views”? What are you considering a “View” in this context? Is your “View” a long string of static HTML?

If that’s the case, I’d think carefully about what it is your view is actually trying to achieve. The HTML and the content are two VERY different things. In MVC the view should be able to be substituted. Can your view be used to generate a PDF? An image?

I’d argue your views aren’t views. Separate out the HTML and data and you’ll have a much better time of it. So instead of:

<h2>This is my view!</h2>
<p>With some basic html content</h2>

Your view should look like this:


Store the title and content in the database and the view in the filesystem. The difference in flexibility is huge. You can change the view HTML structure and it will affect all your pages at once.

The nature of what I’ve built so far allows me to build views in the filesystem that are copied to the DB via CLI. When changes are made in a filesystem view a simple CLI command updates the DB version. Normally these views would only be for very simple static type pages. HTML markup in these views is minimal, as these views are nested in a main template type view. These views are essentially content, but nevertheless, some HTML does exist in them. Up until this point, all of my views that are content like this have existed in the filesystem. The app is not a CMS, so content has to exist somewhere.

DB is currently like this:

CREATE TABLE `views` (
  `id` int(10) unsigned AUTO_INCREMENT,
  `path` varchar(128) NOT NULL COMMENT 'the location of the filesystem view',
  `uri_string` varchar(128) COMMENT 'HTTP link to the page where content is found',
  `title` varchar(255) COMMENT 'title used in search results',
  `desc` mediumtext COMMENT 'description used in search results',
  `last_mod` int(10) unsigned NOT NULL,
  `data` text COMMENT 'the actual content',
  PRIMARY KEY (`id`)

In config I can switch at any time so I am using the filesystem view instead of the DB version. This is nice for development, as I don’t have to keep updating the DB via the CLI command. These views would be for the only pages on the website that would be cached. Other stuff is too dynamic. Because of this, searching the DB version of the view (which is basically static content) is easy using MySQL (or whatever DB I feel like using).

@TomB, your example is too basic, and if I had a website that was so simple then it would absolutely be a good solution. My problem is that instead of just having a header tag and a paragraph tag, I might have those plus 20 more and 3 lists, and etc and etc. There’s no clean solution for creating a site search when the content can vary so greatly, or at least I’ve just never seen anything like that. So what do you do to search content which varies so greatly? How do you store it? How do you query for it? I’m trying to go for the most simple solution, and this is all I could come up with.

To answer your questions, I do have views that can generate a PDF, but only because I’m using DOMPDF. I do have views that create XML output. Images in views are sometimes hardcoded in <img> tags, but uploaded images may also be stored in the DB or filesystem. Remember, my use of views stored in the DB would be limited to static type pages. The whole point here is to be able to search those pages.

Although I’m actively developing this solution, I haven’t implemented it yet, and still very open to modifications or going in a completely different direction. I am listening!