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