我目前正在一个自定义框架中工作，该框架使用数据库来设置一个页面对象，该对象包含关于模块、视图、控制器等的信息，前端控制器使用该信息来处理MVC模式中的路由等（显然）。
处理数据库中页面的最初原因是，我们需要能够在管理界面中动态创建新的登录页面，还需要创建其他动态对象可以附加到的onLoad和onUnload事件。
然而，在昨天阅读了这篇文章后，我想知道我们是否应该将这种处理从数据库中移除，并像其他框架一样使其全部由文件结构和代码驱动，这样就可以在不将数据库作为组件的情况下对页面进行测试。
我目前正在考虑是否放弃自定义框架，使用其中一个标准框架并对其进行扩展（这是目前最有可能的），但我想知道是像现在这样扩展框架以通过数据库处理页面请求，还是应该简单地使用框架附带的任何路由/处理机制？
通常我对在"玩具"应用程序中允许进行的操作非常宽容，但我认为无论如何都应该避免一些坏习惯。数据库是功能强大的工具，通过存储过程使用相当强大的语言来完成您需要做的任何事情。。。但它们确实应该用于存储和扩展对数据的访问，并强制执行低级别的数据一致性规则。
在几年前，将业务逻辑放入数据层是很常见的，但关注点的分离确实有助于提高应用程序在其使用寿命内的可维护性。
请注意，使用数据库而不是文件系统来存储页面模板并没有错。在未来，这两者之间的界限将进一步模糊，我有一个系统，由于低预算托管以及需要如何保存动态生成的内容的问题，所有模板都在数据库中。只要你的框架可以很容易地从文件或字段中提取模板并对其进行处理，无论哪种方式都无关紧要。
另一方面，昨天的帖子是关于直接从数据库生成UI层元素的（至少我是这样读的），而不是一个不寻常的模板存储位置由于上述原因，这是一个令人深感担忧的问题。。。数据库将锁定到web应用程序，并且仅锁定到web程序。
第三方面，如果你有一个运行良好且易于扩展的系统，就不要太在意别人的建议。每个用例都略有不同。如果您的可维护性没有受到影响，并且满足了业务需求，那么它就足够好了。