Top 3 reasons not to develop a “blog system” that

Question

In this question the OP implies that he wants to base the blog system he is developing on automatic creation of .aspx files, one for each new blog entry. In my answer to his question (which is related to something else), I told him that I would discourage him from using such an approach, but without giving any real reasons. He is now wanting reasons why it is not a good idea, and I'm using this question to see if the community can come up with a compelling enough list of reasons for him to use another approach, such as one using a dbms, code-reuse, url-rewriting, MVC, and what not.

Answer 1

.aspx pages are for dynamically generating html (and javascript etc.). Either the same small set of .aspx pages should generate output for all the blog entries (stored in a series of fields) or (for performance reasons) pre-generated html could be stored in the db (best) or .html pages.

Generating an .aspx page for each blog entry is generating the tool for generating content. It doesn't make sense for any normal. There will be needless overhead in that system. Without knowing his exact plan, I can still be sure that at least some of the following apply:

• duplication of code in the .aspx pages, great difficulty updating the layout/behavior of the site
• substantial and needless overhead from IIS having to process and constantly recompile many extra .aspx pages.
• searching will be a nightmare, as the content will be in files. Difficult to set up and it will never be efficient.
• editing, adding comments, moderating will be . . . really hard.
• security will be complicated

Answer 2

Generating separate ASPX files for each article is inefficient use of server resources:

• every new aspx file will get compiled to a DLL. This means an additional execution time overhead for compiling the article + memory overhead through recreation of a new AppDomain that contains this new DLL

• it's possible to configure ASP.Net to compile all ASPX files in a single DLL file, but that would be even worse: ALL articles will have to be recompiled every time a new article is generated

A more acceptable solution (but even then, not the one I would recommend) would be to generate static .html files.

Answer 3

There are two broad kinds of CMS publishing platform:

• Those who generate the content statically. Some publishing platform generate the content statically. In this case the generated files are not dynamic and should be HTML files. The system must have the ability to regenerate everything, for instance, if a template changed. There was a time when this solution had some advantages:
  • security: security is managed at the file system level
  • search: fulltext search was easy because everything was file-based
  • performance: uses less CPU.
  • interactivity: not possible
  • content dissemination: the only reason now to build or choose such platform is if content need to be disseminated through other channel than the web, e.g. CD, downloadable journal, etc.

.

• Those who render the content dynamically. For web site, the easiest way is to render the page dynamically.
  • security: security can be checked using complex scheme, etc.
  • search: search system have evolves and integrate nicely with heterogeneous sources now: can be full text in database, files, etc.
  • performance: this is no more an issue.
  • interactivity: this is a lot more flexible: content can be adapted to the visiting user, people can rate the page, add comment, etc.
  • content dissemination: needs to be online, of course

A hybrid system were you generate statically file that will be rendered dynamically (.aspx) is to me a non-sense -- it has the disadvantages of both.